I’m trying to populate a field of a RunBaseBatch Dialog without prompting it, than I need the value I previously inserted get out from the pack method.
dictClass = new DictClass(className2Id("BatchClass"));
rbb = dictClass.makeObject();
dialog = rbb.dialogMake();
dialog = rbb.dialog();
fbc = dialog.formBuildDesign().controlNum(1).controlNum(1).controlNum(2).controlNum(1);
fbic = fbc;
cont = rbb.pack();
When I look in to the container I see the default values of the batch that in my case are setted during the dialogPostRun method.
I think that I’m missing something but I can’t figure out what.
I’m doing this because I need to map the fields on the dialog to the position in the packed container that is obviously the same as che CurrentList macro but is not surely the same of the fields order in the dialog.
Any help is greatly appreciated.
Do I understand correctly that you want to populate class variables of a RunBase class, and you don’t want any dialog at all? If so, you don’t need to “populate the dialog” at all. The point of the dialiog is getting values from users, and if you don’t want that, you don’t need any dialog.
Do you want to explicitly set values in code (e.g. 11111 in your example)?
If so, you can do something like this:
MyBatchClass myBatchClass = new MyBatchClass();
If the method for setting the variable doesn’t exist yet, you can create it.
(If you used the SysOperation framework, you would use a parm method of a data contract class.)
If you want to get a packed instance of the class (which you can later pass to unpack(), simply call the pack() method:
container packedClass = myBatchClass.pack();
yes but no I can’t do that, the solution have to works with all the RunBase class already existent and future development.
I already have a working solution for SysOp.
I need to pass through the dialog because in there I can check data types. I suppose that if I populate a container, unpack it (of course with the right size) and than check the dialog there are too much unknowns.
than I generate and loop through the dialog to find that the only field is a DateTime I don’t even know what I get nor If that can raise an exception… Things that can’t happen passing through the dialog and than check the container.
Okay, can you please explain what you’re trying to achieve?
How will you get into situation that you’re trying to unpack a packed instance and you find invalid data there? If it’s because of data of an older version of the class, the unpack() method should be able to handle it, if it’s implemented correctly. Unlike you example, the container should contain a version number.
And how will a dialog help you with data type checks?
I need to map the position of every dialog field in the packed container of the corresponding RunBase class.
(this is my need if I have to tell why, this will be a very very long post with probably a lot of useless information, but if you have another way apart from looping through the dialog I will gladly read it)
So my idea is looping through all the fields one by one, putting an ad-hoc value in the field and search that value in the packed container.
(every time there will only be 1 field not empty so I will get in the packed container only default values for the others)
(Answering your last question: checking the type of the field before putting in the ad-hoc value allow me to avoid wrong type assignment)
About my previous example yes of course in the first position we will have the version I just semplificated the example but maybe I had have tell you
About your second question, I don’t know what contains the class I can only know the length of the container thanks to the pack method and of course I know that in the first position there will be the version, no more than that. So it’s not about an older version is that I don’t know which class is being processed in fact in my first code I was using a DictClass to imply that it will be every possible extended RunBase class.
Sorry about my bad English like you can imagine it is not my native language. If it is not clear please tell me and really thank you.
I’m sorry, but there is no way to implement your requirement “to map the position of every dialog field in the packed container” in a generic way. These are two independent things. Some values are not displayed in dialog fields (e.g. queries and values that users shouldn’t change, such as record IDs of selected records) and dialog() method can add dialog fields that aren’t bound to any variable later packed to a container. For example, there may be additional details helping users with selecting right values. And even if everything matches, you would have to analyze code to know the relation between the two.
Fortunately it doesn’t mean that everything is lost. What you’re talking is not a business requirement; it’s just your technical design. And while this design can’t be implemented, there may other solutions for the actual business requirement.
If you want our help, you will have to explain what you want to achieve from business perspective. If you think it’s not worth explaining, then we’re done here.
By the way, your English is good; there is no problem with it… And I’m not a native speaker either.
It’s not that it is not worth it, I’ll try to keep it simple either because it’s a big develop and I don’t know how much the NDA permit me to disclose.
I’m writing a tool that allow to define various type of check like on system load etc and based on that execute, hold or postpone the start date time of batches that are previously opportunely configured. Batches needs to be distinguished by their class and their parameters or only a portion of their parameters.
This last part “only a portion” give the need to know where every variable is stored in the Parameters field of the batch.
I don’t care about values that are not displayed nor about values that are displayed but not packed, in the first case I can’t send a value through the dialog and get it from the pack so out of sight out of mind, in the second I send the value through the dialog and than can’t find it in the pack good for me one less to care.
WindowControl, ButtonControl etc other things I don’t care so there is no problem.
If I can figure out how to actually set the value of the variables batch through the dialog but without prompting it I’m pretty confident that there will be no problem at that point I’ll save their position in the pack and than in the batchRun I can recognize the configured batch.
It’s clear enough?
I can’t figure out why if I’m getting a reference to the batch’s dialog, setting a value, calling the getFromDialog method I don’t get that value but the old value. There are just 2 option for me:
what I’m getting it’s not a reference to the dialog
I need to call some other method before the getFromDialog that actually “save” the value in the dialog’s field
Another way I was thinking is to “force” a closeOk method on the dialog just after the run, in that case I suppose that the value will be actually changed. But well, the previous solution is not really “Elegant” this one look terrible. [emoticon:6d505171faa4497c85c5ca27290c555d]
Thank you I’m working hard on my English skill [emoticon:c4563cd7d5574777a71c318021cbbcc8]
Let’s consider the following scenario.
You select a record and click a button to process it. For example, let’s imagine that it’s a sales order and the process will create an invoice (the real process is much more complex, but this just an example). The button calls a RunBaseBatch class and passes RecId of the sales order. A dialog is shown, but the RecId is not there, because you’re not allowed to change it. You can merely set batch processing options and either confirm or cancel the dialog.
If you look at dialog fields, there is nothing. But the class doesn’t make any sense without the RecId of the order to post. How do you want to pass this RecId if you consider only dialog fields and there is no such a field?
In that case that particular batch doesn’t need to be configured for the “management” or maybe I can chose to configure if to run only if tlog in the db is less than 10% occupied (just an example) but the recid obviously is not a thing that need to be considered.
Consider a batch that every 4 hours process 10000 sales order creating 10000 (10000 is a variable that is set from the dialog) invoice that batch will occupy various resources and maybe I want to execute that only if the system comply to a series of check and the checks change if the orders are 1 million. in this case I can configure two version (or more) of this batch 1 for the batch that process 10000 order 1 for the 1 million version.
To be more clear not every batch need to be configured to be a part of this process but there are some that can.
I don’t want you to agree to the business necessities, nor am I who decide what is useful or not I’m just the one that have to do the job
It is a pleasure to speak with you but to get to the topic, have you any idea of how to populate the fields of the dialog without prompting it and than pack that values supposing that the fields have a some sort of usefulness and are linked to the variables of the currentilist?
Now we’ve contradicted the requirement that “the solution have to works with all the RunBase class already existent and future development”. But now we don’t have any definition of what it must support and what will be excluded. Regarding my example, you said that “[this] particular batch doesn’t need to be configured for the “management””, but how will you distingush those that you don’t want and/or your solutions isn’t able to support?
Regarding “do you have any idea of how to populate the fields of the dialog without prompting it and than pack that values”, you surely can call dialog() method to get a dialog and look at dialog fields. But I have no idea how you want to populate them with values.
By the way, you may be interested in Batch Parallelism in AX. It explains things like creating batch tasks at runtime.
Never said that the solution will be unable to support your example batch, like I had explained previously if the dialog does not contain that field I don’t care about that variable.
Your batch example is “setuppable” in the solution without that parameter that in fact for the solution doesn’t exist.
But either if that recid was a modifiable parameter shown in the dialog when I said “a portion o their parameters” 0 is a portion too. So from the solution I can chose to ignore it. Or to be more precise I’ll be able to ignore it whe I finally figure out how to do what I was asking.
By the way thanks for the conversation. it is a really big development and I probably wasn’t able to explain it for good.
Hmm… if you don’t care about the variable, then you can’t run the class. I thought you wanted to be able to populate variables and running the class, but now youy seem to be satisifed even if you’re unable to do that.
I’m afraid that I can’t help you without information about business requirements. Sorry.
Maybe someone else will need the solution so:
the dialog object contains a Map called name2dialogClass that contains every DialogField added to the dialog (and also DialogGroup etc).
Looping through it is possible to set a value simply with dialogField.value(SOMETHING)
than calling the getFromDialog method of the RunBase the setted value will be assigned to the right variable and as I wanted packing the runBase it is possible to find where the value is in the container.
Now there are 2 exception, doesn’t work with RunBase that have runOn property setted to server nor with RunBase that use a form object for the dialog.