If a window or control sends a quickevent message, can the target window/control find out who the sender is, or do I have to put that information in the message parameters? I have various MDI child windows that can send OMNIEVENT messages to the frame, and the frame needs to know which window (or even control) that sent them.

If the target window/control cannot find out who the sender is it would be nice if I could include @WINDOW among the parameters. But it seems that syntax isn't allowed. That's a pity.

My suggestion for a workaround is to make a stored procedure that (1) accepts all the other parameters I need for the message, (2) picks up the value of @Window and adds that to the other parameters and (3) does a Send_Event OMNIEVENT. Then I run that stored procedure from the quickevents instead of the OMNIEVENT message. Does this sound like a sensible solution? (I haven't got much practice with this kind of thing.)

I run OI 3.3, by the way.

- Oystein -

Oystein,

There is a property that tells you that last control that had the focus. If I understand your question correctly the PREVFOCUS property is something you might want to look at. Here is an article that will help you with it.

Good Luck…

Blaise

Oystein,

If the target window/control cannot find out who the sender is it would be nice if I could include @WINDOW among the parameters. But it seems that syntax isn't allowed. That's a pity.

Are you sure you can't pass @WINDOW. I'm almost positive we're doing this very thing. Make sure you enclose @WINDOW in single quotes (i.e. '@WINDOW') in the parameters field and it should show up in Param1, Param2, etc., depending on what parameter position you used.

dbakke@srpcs.com

SRP Computer Solutions

Don,

Are you sure you can't pass @WINDOW. I'm almost positive we're doing this very thing. Make sure you enclose @WINDOW in single quotes (i.e. '@WINDOW')

Thanks. That was it. I didn't use quotes. I thought of @WINDOW as a variable. But I realise now it is interpreted in a different way/place than I thought. (I remember feeling pleased when RevSoft introduced the possibility of using @WINDOW (sorry - '@WINDOW') in quickevents, but I never actually tried it until now!)

But I am still curious to know if there is an answer to my original question - if the target can find out who the sender is, without any help from parameters. I might have come up with a reason (still somewhat vague, though) to want that ability.

- Oystein -

Blaise,

I think this could help me in some situations, but not in the general case. The initiative for the event might perhaps come from the control that has focus - or as you suggest: the previous control that has focus - but there might be sort of a chain of command where who's responsible for sending the event is different from the one taking the initiative. E.g, let's say there are child windows for various related tables. This one child window bound to table A with a field for a foreign key to table B discoveres the user has changed the key value, so it notifies it's superior - the frame OMNIVENT handler, perhaps. The frame OMNIVENT handler investigates and finds out there is a child window for TABLE B open that's supposed to show the row for the current value of that foreign key, so it changes the key in the B window and sends it a READ event. But READ events could also originate in the B window itself, perhaps, and… eh… umm… … well I haven't really thought this through yet, but it'd be nice to know alr

eady now if there is a general way to accomplish what I asked about.

But thanks anyway. I wasn't aware that you could find out the previous focus outside the current window even. I'm sure I'll need that info sooner or later!

- Oystein -

Don,

Triggered by your reminder that it's possible to use '@WINDOW' in various quickevent parameters I decided to go back to a problem I once had when I developed a lot of windows by cutting and pasting controls from other windows. I had lots of quickevents that returned values to e.g FIRSTWINDOW.EDITLINE that had to be painstakingly changed into SECONDWINDOW.EDITLINE (and I always forgot some of them of course). I so much missed the opportunity to use @WINDOW.EDITLINE or something. And now I discovered that this really works!!! Without quotes this time, though.

It's still not good enough, of course. FD should have as default the '@WINDOW.' syntax. That would also kill a different problem: If you make quickevents before you save the window you easily get your values returned to UNTITLED.EDITLINE.

- Oystein -

Oystein,

I so much missed the opportunity to use @WINDOW.EDITLINE or something. And now I discovered that this really works!!! Without quotes this time, though.

Oh my gosh, I couldn't have lived without being able to do this. Hardcoding the window name is useless with multi-instance windows.

It's still not good enough, of course. FD should have as default the '@WINDOW.' syntax.

This part I don't get. The default for me is nothing. I always have to explicitely specify a control and property name for return values, which is great because the majority of my QUICKEVENT don't need to return anything. Perhaps OI 3.3 behaves differently and I forgot since I moved to 3.4, 3.5, and now 3.6 as soon as they were available.

dbakke@srpcs.com

SRP Computer Solutions

If it's not a lost or gotfocus command, you could check the focus. Isn't always acurate, but it's a start. The RETSTACK() function might contain some information as well.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron,

As usual you are right on (pretty 60's huh) ..

Use of retstack() gives the information BUT you have to extract it

In the code snippets below I give the retstack results. Now this is a simple example BUT if one *knows* what should be on the stack (the calling chain of routines etc) then you should be able to get the needed information from the retstack. Yes?

Example: A window with a button and a sp ..

* Click Code: *

Declare Function RetStack

Declare Subroutine FooBar

Stack=RetStack()

debug

(stack=$$$SYSPROG*CLICK*TEST.BUTTON_1:@VM:RUN_EVENT)

Foobar()

Stack=RetStack()

debug

(stack=$$$SYSPROG*CLICK*TEST.BUTTON_1:@VM:RUN_EVENT)

RETURN 0

Code for sp:

Subroutine FooBar(a)

Declare Function RetStack

Stack=RetStack()

debug

(stack=FOOBAR:@FM:$$$SYSPROG*CLICK*TEST.BUTTON_1:@VM:RUN_EVENT)

Return

Don,

Me: I so much missed the opportunity to use @WINDOW.EDITLINE or something. And now I discovered that this really works!!! Without quotes this time, though. You: Oh my gosh, I couldn't have lived without being able to do this. Hardcoding the window name is useless with multi-instance windows.

Ooops! I've not yet used multi-instance windows, but I will probably very soon.

Me: It's still not good enough, of course. FD should have as default the '@WINDOW.' syntax. You: This part I don't get. …

"Default" was the wrong word. I meant "suggested values". What I meant was: In the Quickevent Window there is a list box for choosing which control to return the value in. The choices in the listbox are - in addition to the useful @SELF, @WINDOW and a few similar ones - all in the hardcoded form WINDOWNAME.CTRLNAME. Why couldn't they be in the more general form @WINDOW.CTRLNAME instead?

- Oystein -

Aaron,

The RETSTACK() function might contain some information as well.

Well, I won't find out until I upgrade from 3.3… I'll see if I can get around to it after that wedding…

- Oystein -

Pretty heavy, huh?

As you said, it gives back the list of all codes in the stack, but you have to extract it. You also have to know what you're looking at. Basically, everything ends (starts?) with RUN_EVENT, so, in theory anyway, you could start and move back to the first RUN_EVENT found in the list and that's what called called this logic chain. Trouble is, depending on where you're at, or what you want, it could be the event before or after the RUN_EVENT.

So, if if I'm in a stored procedure, and want to know what event started this cycle, it would be the event executed after RUN_EVENT. If I'm in an event, and want to know what triggered this, it could be from the event executed before RUN_EVENT.

For example, if a GOT_FOCUS event sends a READ event, and the READ event sends a OMNIEVENT and the OMNIEVENT calls the procedure, and you want to know what started this chain, you might have to go down a few chains until you find the GOT_FOCUS event.

Of course, the first program on the list is the current code, and it works back through calling routines, but the information's there.

Personally, I prefer passing @SELF, @WINDOW or just jaming the event name into a parameter so I don't have to deal with this. Easier when starting an application from scratch. Wouldn't want to do it for an app with hundreds of windows and thousands of events. But, at standard Sprezz consulting rates……

apk@sprezzatura.com

Sprezzatura, Inc.

I recall testing this and when the window is executed, it actually treats this as @WINDOW, at least if the return control should belong to the current window. If you are returning the value to a control in another window, then there could be a problem. You'd have to implement this yourself.

apk@sprezzatura.com

Sprezzatura, Inc.

Aaron,

I fully agree .. I find it much easier to pass CtrlEntId and Process.

dsig

David Tod Sigafoos ~ SigSOlutions

dsig@teleport.com cis:70302,77 voice:503-639-8080

Geez, Dave. We can't agree. It might destabilize the harmonics of the universe at best. At worst it could cause a GFE.

apk@sprezzatura.com

Sprezzatura, Inc.

View this thread on the forum...