There seems to be a problem with executing a popup from the System Monitor. (plus some irregularities with MSG)

Below is the output in the System Monitor for running the entities TEST_HELP, TEST_MSG, and TEST_POP.

The dots (…) are not mine; they are from the system.

run repository 'EXECUTE','MYAPP*APPNOTETEST_HELP' 1 . RUN_EVENT calling:SYSPROG*CLICK*APPNOTE … run repository 'EXECUTE','MYAPP*MSGTEST_MSG'

1

.

run repository 'EXECUTE','MYAPP*POPUPTEST_POP' RUN_EVENT calling:SYSPROG*..OIWIN* … REPOSITORY (EXECUTE,SYSPROG*STPROCEXEPOPUP_SUB, …)

.

The APPNOTE TEST_HELP appears just as it does in the TestRun of the UI design window.

The MSG TEST_MSG appears, albeit with a somewhat different style.

It includes the 'Yes','No', and 'Cancel' buttons, but not the 'Help' button.

The 'Help' button triggers a call to the APPNOTE TEST_HELP.

This function works during TestRun in the UI design window, but is absent when called with Run Repository.

The "full version", i.e. with the same look and with the 'Help' button sometimes appears when the entity is SHIFT-Double clicked from the Repository outline and sometimes the simple version appears, i.e. without the 'Help' button.

But the POPUP TEST_POP is not executable at all from the System Monitor. Nor is it executable by SHIFT- Double clicking it in the repository outline or through the menu with Entity-Execute.

The version of OI is 4.1.2

Any ideas??

Popup and MSG need the context of a MDI Frame or Form to execute properly.

Execute them from the menu on an MDI or from an event on a Form. EXEC the form or MDI from the system monitor.

MSG executes from the System Monitor (albeit without the extra 'Help' button) and the APPNOTE executes from the System Monitor. And both execute by SHIFT-DoubleClicking in the Repository. A popup also exectues in TestRun, so that means that it should also be able to execute, like the MSG and APPNOTE from the System Monitor or from a subroutine which is not tied to a window. At least that is what I would imagine. After all, you can build a MSG and call it from a subroutine. Why does this not work with a POPUP?

Sprezzatura or SRP will correct me if I am wrong but it is my understanding POPUPs require Event Contexts that are inherited from a MDI Frame or Form. The WindowsAPI that MSG uses is written by Microsoft so that in can without them. The many WIndowsAPIs used by POPUPs are not.

POPUPs are much more complicated than MSG and requires many more GUI elements.

First of all, thank you for taking the time to help. I meant to say so in my last response. However, the static popup is callable as a quick event in the child window (without running that child window from the parent MDI) and is also callable from the child window's same quick event when the child window IS running under the MDI parent. What does not work is:

1) Calling the popup from the System Monitor with RUN REPOSITORY 'EXECUTE'..

2) Calling the popup from a program with

Declare Function Repository

retval=Repository('EXECUTE'..

3) Calling the popup from a standalone subroutine OR even from an event script.

4) Building a popup from scratch in a subroutine (or event handler) and calling it with the Popup function, as I have done thousands of times in Arev.

I was beginning to think that some dll for running popups got erased somewhow, but then the popups would not execute as quick events either. I am utterly baffled.

Again, thank you for your time and interest.

Hi Alexander,

Some things you need to be aware of to help you understand what you're seeing:

The application manager and the system monitor are not "OI windows" as such. i.e. they are not under the control of the presentation server (a.k.a. the PS - What's the PS? It's the subsystem in OINSIGHT.EXE that manages the actual windows your application creates. It keeps track of them, calls into OpenEngine to run your event scripts and commuter modules, translates Get_Property and Set_Property calls into their Windows API equivalents and so on)

When your Basic+ event code (or commuter module code called from QuickEvents) runs in response to an event happening in an OI window it's said to run in "event context". i.e. it originated from a window managed by the PS. If code runs within OpenEngine that wasn't sent from the PS, (such as a web request from OECGI for example) then this is outside of event context.

A side effect of code originating from an event in a OI window/control is that a system variable gets set called @window - this is set to the parent window of the control that originated the event.

e.g.

If you raise a CLICK event from MYFORM.BUTTON_1 then @window will be set to "MYFORM" just before your event code is executed.

If you run code from the system monitor then it is flagged as originating from the PS _but_ @window will not be set as it wasn't raised from an OI window/control.

Now, onto the popup/msg issues …

Both of those routines are built on top of the dialog_Box() function. The main purpose of this function is to display a window, wait for the user to close the window, and then carry on processing after returning a value to the calling program at the point called. In order to do this dialog_Box() expects to have a "parent" OI window, which is used to "anchor" the window it creates. If this parent is not passed to dialog_Box it won't display any window at all.

In the case of msg() the code looks to see if it has been called from event context and if so is there a parent window? If not then it switches internally to a function called msg2() which uses raw Windows API calls to display a message box. The mapping between msg-]msg2 is not exact hence some things are missing, BUT you will see a message displayed when called from the system monitor.

In the case of popup called from the system monitor @window won't be set so there's no parent window to speak of so it won't run.

In the case of the APPNOTE I imagine the code has been written to swap to something like a simple Start_Window() call rather than a dialog_Box call if there's no parent window. I would think this is because APPNOTEs are designed to simply display information, whereas popup is designed to return information to a calling program at the point it was called.

cpates@sprezzatura.com

The Sprezzatura Group

World leaders in all things RevSoft

Hi Carl,

Thanks a lot (and to Warren Auyong also) for the explanation of this baffling behavior. It is a shame that popups cannot be called directly, as they were always my tool of choice. But life is hard, isn't it?

I seemed to recall having read somewhere about the two different flavors of MSG (not Mono-Sodium-Glutamate) and that certainly could explain why the MSG records can be displayed in a different format and with reduced functionality.

View this thread on the forum...