Error ENG 0711: too many arguments passed into a Dialog_Box

alvaroafernandez

Bottom line first: how do I reliably pass more than one arg to the CREATE event in a commuter module?

Background
I have learned from experience (and the good folks on this forum) to use commuter modules rather than form-bound event handlers. So far this has been a good thing.

One thing that has come up is that there seems to be an undocumented limit (?) on the number of args I may pass into a commuter module via a Dialog_Box call.

If you select "Call a commuter module" as an option, passing up to 6 args seems fine and I've gotten that to work in other contexts.

My situation is I need to pass in 9 for this program. So I (naively?) modified the string in the "Call commuter module" section, to have '@PARAM7',... all the way to '@PARAM9'.

But - I get an error when I call the Dialog_Box - I have 'too many arguments' it says.

I experiment by taking arguments out, and find that I can only get away with passing 1 argument (plus the DialogID and ParentID of course). This is weird - I've been able to pass in more than one argument before, but I can't tell what's changed that now it will only accept 1.

I also tried to change the call to explicitly call PHS*STPROCEXE**PHS_BUILD_TYPE_DF_EVENTS under "Send to Entity", and the error persists. Have I wandered into another corner case?

AusMarkB

If you check the script handler for any event, you will see how many arguments it accepts.
Create sends just the one, "CreateParam".
To send multiple through dialog_box, (and therefore the create event), you can use an array for createparam rather than separate arguments.

DonBakke

@alvaroafernandez - You are fighting two limitations. First, Dialog_Box itself will only accept one argument to pass into the window. There really is no way of getting around this other than doing what @AusMarkB suggested.

In addition to using the Script Event editor, you can also use the Event Designer to see what arguments are supported:


The reason I am pointing this out to you is because you can add more arguments using the Event Designer. Simply edit the Event Parameters, add more event arguments, and click Save.

However, this will not fix your Dialog_Box limitation.

alvaroafernandez

I guess I was led astray by the fact that when you select a Commuter module as the preferred response to - well, any event - OI shows you 7 parameters. I guess they're not checking which event this is for. In fact I know I've done this before - passed in multiple arguments to CREATE - and it's worked fine. It was only when I increased the argument count (from 7 to 9) that OI suddenly remembered "Hey! It's only supposed to be 1 argument, buddy." :-)

I'll like the array approach, but I'm surprised. I assumed an array of N elements would count as N variables, and would thus not work. What I did as a workaround was to concatenate all the 9 @FM arrays into one variable and use a "~" as a delimiter; then I used

field(p,"~",i)

to extract the i-th argument inside CREATE. Like fieldstore, but simpler...

Also, while I think arrays might be faster, or at least less fragile since I'm not depending on ~ being not used (comments?)... I *also* need to store these contents for the form to use, so I was stuffing them into a hidden field - hadn't heard of MISC until recently - and it's unclear i could stuff an array into MISC or any text field.

AusMarkB

Concatenating using "~" is essentially the same thing, just using your choice of delimiter; a "~" instead of fm, vm etc. I didn't realise the 9 variables were already @FM arrays but the logic still applies. If the variables are only @fm delimited, then you could swap them all down a level to @vm and then make the createparam an @fm delimited array of @vm delimited variables thus eliminating any concerns about unexpected uses of "~".

var1 = a:@fm:b:@fm:c
var2 = 3:@fm:4:@fm:5
var3..... var9

swap @fm with @vm in var1
swap @fm with @vm in var2
swap...

createparam = var1:@fm:var2:@fm:var3......

As for storing, either would work as long as the variables aren't @rm delimited.
An @fm array can be stored in a hidden text field or
into the window MISC property or
into any other user defined window property, for example

set_property(@Window, "@SOME_NAME_I_MADE_UP", createparam).

Personally, I most often use the latter, but I'll use a text field if I want visibility of it during development/testing and then I can just make it invisible when I'm satisfied it's working.

alvaroafernandez

It's actually 9 arrays, each one of them @FM delimited (and some may be @VM delimited within that as well). :-) I'll give the dimensioned array a try - it's intriguing. I assumed an array of N entries would be seen as N variables and wouldn't work or I would have tried it.

DonBakke

I'm fairly positive you won't be able to send in a dimensioned array. This would require the routines handling the data to have defined the arguments in advance that way.

Dynamic arrays work because they are, after all, nothing but strings. However, some system delimiters (usually @RM or @STM) do not pass safely through event handlers because Revelation often uses system delimiters for their own purposes. Thus, it is safer to use @FM through @TM.

Another approach is to simply pass through JSON strings. This allows you to create a structure that is as simple or complex as you want it to be while also providing a pseudo-schema (i.e., via the key/value pairs). Thus, it is extensible, self-defining, and you never have to worry about protecting specific positions within a dynamic array.

You can store pretty much anything you want in the MISC property. However, as @AusMarkB pointed out, a User-Defined Property (UDP) is better because you can create as many UDPs as you want and then name them to something meaningful. For those with an AREV background, these work similarly to storing data in the Windows Registers.

AusMarkB

I was referring to dynamic arrays rather than dimensioned arrays but, you know what, I prefer @DonBakke's recommendation of using json, better.
In fact, every time he suggests that, I think, yep, that's a great idea and then promptly forget to implement it next time I have an opportunity. Just fall back into old habits I guess.
Use json. It will be simple if you're familiar with it and worth learning if you're not.
Nice reminder thanks Don.

Is Don. Is Good.

Opto_Will

HaHa!!! Gold @AusMarkB!
I like it! I like it a lot...

For our non-Australian friends, Don's is a smallgoods company here in Oz (Deli-style cold cuts like salami, frankfurts etc.) Their slogan (and website from memory) is "Is Don, Is Good".

Also, I know that feeling. From the 'Great idea Don' straight to the 'promptly forgot' :(
Mind you, Don showed me @Window UDPs once upon a time and now I go gangbusters with them so sometimes it does in fact stick ;-)

AusMarkB

:) I didn't realise that was their website as well.
Classic!
www.isdonisgood.com.au

The type of ad that spammed our tvs in the 90's, possibly 80's as well.Is Don. Is Good

Opto_Will

Shhhh!!!
You're showing our age ;-)
Next thing you wil be telling me "not the Dart..definately not the Dart"

AusMarkB

:D they always think it's the Dart

alvaroafernandez

I ended up using UDPs after some thought. I think it's the most self-documenting way to do this. Thanks for the advice guys!