Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Dialog Box automation
I will try and keep this simple so that I can be shot down easily.
There is existing code in our system that calls a Dialog Box. Some info is checked, some buttons are pushed by the user and a resulting ReturnString is returned when the Dialog box closes. All well and good. Has worked for them for years now.
However, now there is a request to automate this in certain cirumstances.
This will involve feeding it slightly different input data and then programatically triggering those buttons being pushed to fire off their calculations. The RV is to be captured at the end of this process as per normal as the 2nd Button will eventiually close the Dialog. This process will repeat a handful of times rather than the One by One it was originally designed for.
I thought I would be smart and pass through an extra CreateParam in the delimited source data so I can control if it runs in 'normal' mode or 'auto' mode. The problem I have is that I cant get the CREATE to trigger SEND/POST Events.
So my easiest solution is to ask if there is a reason I cant do a SEND_EVENT at the end of the Dialog Create?
Unfortunately, the code isnt modular and does not exist as a re-useable service and is written in a less-than-generic way so I am trying hard to avoid converting all that code to services and testing all the variations to make sure I didnt break existing functionality before I start with the new....
Probably should be done regardless but a tight budget on the project that is already likely to be blown with the next project already lined up. Not a fire I want to put out now If I can help it....
There is existing code in our system that calls a Dialog Box. Some info is checked, some buttons are pushed by the user and a resulting ReturnString is returned when the Dialog box closes. All well and good. Has worked for them for years now.
However, now there is a request to automate this in certain cirumstances.
This will involve feeding it slightly different input data and then programatically triggering those buttons being pushed to fire off their calculations. The RV is to be captured at the end of this process as per normal as the 2nd Button will eventiually close the Dialog. This process will repeat a handful of times rather than the One by One it was originally designed for.
I thought I would be smart and pass through an extra CreateParam in the delimited source data so I can control if it runs in 'normal' mode or 'auto' mode. The problem I have is that I cant get the CREATE to trigger SEND/POST Events.
So my easiest solution is to ask if there is a reason I cant do a SEND_EVENT at the end of the Dialog Create?
Unfortunately, the code isnt modular and does not exist as a re-useable service and is written in a less-than-generic way so I am trying hard to avoid converting all that code to services and testing all the variations to make sure I didnt break existing functionality before I start with the new....
Probably should be done regardless but a tight budget on the project that is already likely to be blown with the next project already lined up. Not a fire I want to put out now If I can help it....
Comments
Dialog_Box creates a modal behavior by disabling the parent window and going into a tight loop while the actual dialog is running. The purpose of the loop is two-fold:
- Check to see if the dialog has been closed (ala a typical close process or the End_Dialog).
- Call the Yield() statement so that event handlers in the dialog can be processed.
This loop and the way events are queued and then called when the Yield() statement is ran is the cause of many problems, especially our OLE controls when events are configured as synchronous. My theory is that this is the source of the conflict you are experiencing with your SEND/POST events. The engine is just too busy to process your event request.There might be ways of circumventing this using lower level calls but I think you might get better results doing the following:
I did some experimenting and I have managed to work around my issue with calling it as a MDIChild and using the 'Auto' flag as a if/then wrapper around the End_Dialogs that otherwise sets one of the Global @USERs variables to return my MV data string.
I will, however, try your suggestion out of interest. Having never used a TIMER Event before, it looks like I also need to set a TIMER Property.
As per usual @DonBakke, a very informative response. Much appreciated.
Are you going to suggest maybe setting a COMMON variable to move data between forms is better practice?
We stumbled across this just today : Yield or Die
Oh yes. I have a not so secret aversion to the @USERx and @RECURx system global variables. I try to mention this in every intro to OI course I teach. They are landmines. If you tell me that you have these fully documented and everyone on your team knows exactly how they are to be used (so as to not step on each other's toes), then I'll relax a bit...but I have never seen this done. On occasion I'll see a general consensus that @USER4 <1> (as an example) will always be used to store "such and such", but I have never seen a broadly documented proper use for all system global variables. Even if fully documented, without tribal knowledge, they are meaningless. Unlike local variables, labelled common variables, or even Hashtable keys (ala Memory_Services or SRP Hashtable), they are not self-descriptive.
Yep. Good stuff. This is partially what I was referring to regarding the OI 10 overhaul.
I think you know us well enough to know that nothing you indicated is true here and that the @USERx has been widely used long before my time. No relaxing for
youme!Since you introduced me to the wonders of a UDP for the Window I have replaced MANY @USERx variables designed to carry data across internal Events (like carrying some data from a GotFocus to a LostFocus) with a simple UDP.
The ones carrying Data externally have been a little slower to convert, probably because the Commons just aren't second nature here...yet.
I appreciate your nudging us in a Best Practice direction.
I am, of course, now changing my @USERx as we speak...
BTW, I didnt even know about the @RECUR globals. I thought the @USER globals were the only user-definable ones...
However, it turns out I didnt actually read this page properly at all: User-defined Variables
It must have been a 'boys look' at the time! Clearly there in black and white...
I meant to include UDPs in my above list of alternatives. BTW, if you always have a main window (like an MDI Frame) then you can use it as your permanent UDP and thus have it be an alternative to a global-style variable.
In OpenInsight these work exactly like the @USERx globals. They are a throwback to AREV which allowed levels of execution. Hence, if you are running in a window and then use a hotkey to open another window, you would be executing in a new level. @USERx variables would retain their values but the @RECURx variables would be cleared. When you exited the second window to return back to the first window, the old @RECURx values would be restored. OI is based on multitasking architecture so the concept of execution levels is foreign...but a modal dialog simulates this experience.
OK @DonBakke, you are starting to blow my mind! How did I not think to set UDP against the Frame?
Handy bit of history there. Probably why I havn't come across @RECUR variables before then. It just goes to show sometimes it pays to read the documentation.
Is this a holdover from your AREV application or did you choose to use @PSEUDO for convenience? The problem with @PSEUDO, as I think you've already pointed out, is that you cannot inspect it in the Debugger.