I defined custom event ATLASEVENT in event designer, and I call the event with

Status=Post_Event(Parent,"ATLASEVENT","","","PROCESS",ViewProcess,"",CreateParam)

The CreateParam, which contains an @FM/@VM delimited string, is not passed to the event. Removing the blank parameter preceding CreateParam causes the parameter to be passed (or at the least part of it up to the first @FM).

Does anyone know why inserting a blank parameter suppresses subsequent parameters? Or why only the first field of a parameter is passed when the data is @FM/@VM delimited?

Help would be appreciated.

Gerald

Oystein,

Thanks. Actually, this is probably partly my bad. I changed the number of parameters in the Event Designer, but I forgot to add the parameters in the MDI frame quick event where the event was being sent.

But then, you say you have "Documentation" on this? And I've been figuring this stuff out purely by experimentation! Like, using @PARAM1, @PARAM2 works but @P1 and @P2 does not. @SELF returns CtrlEntId, but nothing replaces CtrlClassID?

Someplace in the OI documentation it suggests that 20 parameters are supported in quick events, but you think @PARAM4 is the highest number for pass through. Well, sounds like more experimentation is in order. And there's still the question about @FM not being passed through in @PARAMx variables.

Gerald

Oystein,

I experimented a little more. I think you are right about @PARAM4 being the extent of parameter passing, along with @SELF and so forth.

Gerald

Gerald,

I think you've hit on a limit with Send_Message. My notes say it doesn't go beyond @PARAM4. Your CreateParam is no. 5 (?).

Workaround: Merge two parameters into one.

- Oystein -

Gerald, et al:

I have not been able to read through this thread in detail as I would normally have done so please forgive me if this has already been pointed out. It seems to me that the problem here is specifically with Post_Event. I get the same results that you do, Gerald, when I use Post_Event. When I use Send_Event, however, I get all my parameters and the @FM/@VM delimited parameter stays intact as well.

I don't know when this problem was introduced but it has me a little concerned because we have custom events that have been working since OI16 that use 8+ parameters. I'm pretty sure we use Post_Event to facilitate the execution of these custom events. Perhaps we haven't seen this problem yet because we don't use the additional parameters that much…but I'll have to double check when I get back into the office.

FWIW, my testing was done in OI 7.0. So if this *is* a problem then hopefully Pat will resolve this before it gets officially released. I'll post it on the beta site once I have confirmed it to be a problem.

[email protected]

SRP Computer Solutions, Inc.

Don,

Thanks. So it is not just the oil paint in basement affecting me?

Gerald

Oystein,

I am discussing the use of @PARAMx notation in events, rather than filled in parameters. Events may take up to 20 parameters (now where did I see that written?), but as you point out, only 4 of these parameters can be in the dynamic @PARAMx form.

Gerald

Gerald,

I am discussing the use of @PARAMx notation in events, rather than filled in parameters. Events may take up to 20 parameters (now where did I see that written?),

Send_Event is said to take 2+20 parameters (Event, CtrlEntId, and 20 Paramx ones).

but as you point out, only 4 of these parameters can be in the dynamic @PARAMx form.

What I said was that OMNIEVENT seems to have only 4 @PARAMx parameters. I also said CHAR seems to have 5 @PARAMx parameters. I just did an experiment that confirms the latter. So 4 can't be an absolute limit.

If you want to repeat my CHAR experiment do the following:

- Make a form TEST_CHAR with an edit control (mine was an edit box)

- Define a CHAR quickevent for the edit control…

- …that executes a stored procedure TEST_CHAR…

- …with parameters 'CHAR','@SELF','@PARAM1','@PARAM2','@PARAM3','@PARAM4','@PARAM5'…

- …and no Return value in stuff

- Make and compile a TEST_CHAR function with the following code:

<code>
function TEST_CHAR( Event, CtrlEntID, Param1, Param2, Param3, Param4, Param5, Param6, Param7 )
	virtcode=Param1
	scancode=Param2
	ctrlkey =Param3
	shiftkey=Param4
	altkey  =Param5
	call msg( @Window, "virtcode=char(" : seq(virtcode) : ") ; scancode= : scancode : "; ctrlkey= : ctrlkey : "; shiftkey= : shiftkey : "; altkey= : altkey )
return 0

</code>

- Test run

- Set focus to the edit control

- Key in suitable key combinations and check the message that comes up. Since the @PARAMx we want to prove works - the 5th one - is the altkey parameter, we might want to try key combinations both with and without the Alt key. Unfortunately Alt+char combinations don't reach the edit control. But fortunately some Alt+Ctrl+char combinations do, at least on the Norwegian keyboard. One that I think will work for you too is Alt+Ctrl+E, which generates the Euro symbol.

- Oystein -

Richard,

You said that the parameter dropdown shows @PARAM1, etc. In my version, 4.1.3, the parameter dropdown is grayed execpt for General, MDI_Child, and Index Lookup. However, the dropdown is filled only for index lookup. Sort of explains the @PARAMx part of my confusion. You can't find the docs (F1 in the editor?) and I can't find the options (Alt-Down at parameters?).

Otherwise, your description of parameter passing matches mine. I was just surprised to find that @PARAMx seems to end with x=4, and field mark delimited data is truncated at the first field mark. Either I'm being a dummy as usual, or these are the real limitations.

Gerald

From wayback I had somewhat less confidence in the on-line docs - and built up my own set of documentation plus other sources. But that is changing now, Ira has been correcting and filling out the On-Line docs - even with stuff I had never come across before.

I would have to scratch round to work out specifically how I originally sorted out the @PARAMn, @SELF etc. But was definately from looking at the dropdown options.

Oystein,

Hmm. I'm getting your point, although I am particularly dense today. Must be connected to all that oil-based primer paint I slapped on the basement walls last night. Some pre-defined events accept more than 4 parameters, but what about events you design yourself? This is where my question originated.

I wanted to reserve the OMNIEVENT, so I defined my own event called ATLASEVENT. I gave it maybe 10 parameters, and I used SEND_EVENT to send it the 10 parameters. As far as I could see, only 4 of the @PARAMx values actually made it through to the custom event. I don't know if the limitation I found occurs in SEND_EVENT, or in event definition, since SEND_EVENT has to be used to trigger a custom event.

Anyway, I have resolved this as a problem in my code. Now it is just a question of getting the features and limitations of parameter passing documented correctly in future versions of OI. Thanks much for your help and perseverence.

Gerald

Gerald,

@PARAM4 being the extent of parameter passing

You're talking about Send_Event, now, right?

Because some events do have more parameters. CHAR goes up to 5.

And the SPINALTAP event goes to 11.

- Oystein -

Gerald,

Thanks. Actually, this is probably partly my bad. I changed the number of parameters in the Event Designer, but I forgot to add the parameters in the MDI frame quick event where the event was being sent.

But then, you say you have "Documentation" on this? And I've been figuring this stuff out purely by experimentation! Like, using @PARAM1, @PARAM2 works but @P1 and @P2 does not. @SELF returns CtrlEntId, but nothing replaces CtrlClassID?

Did I say anything about documentation? I think I said "my notes". I've learned from the discussion lists, tutoring at Sprezz UK, and experimentation.

I think I came across this limit while experimenting with the OMNIEVENT event. Studying OMNIEVENT in the Event Editor it seemed to have lots of parameters. But I wasn't able to send so many parameters with Send_Event. I think I concluded there was a limit in Send_Event, but perhaps it's a limit of OMNIEVENT.

After writing this I got curious about how many parameters OMNIEVENT has in Event Editor, and checked with the Event Editor of my current version of OI - 4.1.2. It's not as many as I remember from when I did my experiments (probably back in OI 3.6.1). I seem to remember Param7, but now the highest is Param4.

So perhaps Send_Event can do really many parameters, while OMNIEVENT all the time didn't go higher than @PARAM4. The Param7 I remember in Event Editor is either my failing memory or got corrected to 4 by Revelation since 3.6.1.

Someplace in the OI documentation it suggests that 20 parameters are supported in quick events, but you think @PARAM4 is the highest number for pass through. Well, sounds like more experimentation is in order. And there's still the question about @FM not being passed through in @PARAMx variables.

Can't remember a problem with @FM. But browsing my code I can't find any examples of having used @FM. You might very well be right.

- Oystein -

Gerald,

I never seem to have the docs at my fingertips - so for the event params I just look at the scripted event. Take out the first to Params ie CtrlEntID, CtrlClassID and the remaining are the params to pass. And of cause they are passed as '@PARAM1','@PARAM2' etc. (Thats what the Parameters Options dropdown gives as defaults for some things).

In my case I am usually sending the quick event to a commuter SSP, and my standard parameter passing is -

"EVENTNAME','@SELF','@PARAM1','@PARAMn' as required.

Richard Bright

View this thread on the forum...