I open an MDIChild window, say MDICHILD. The code snippet for the OK button on the window does the following:

End_Dialog( "MDICHILD", Pseudo )

Call SubroutineX

Then SubroutineX wants to open a dialog box, say "DIALOGX", so it goes through the usual dance of

Window=@Window

Parent=Get_Property( Window, "MDIFRAME" )

If Parent NE "" Then Window=Parent

Result=Dialog_Box( "DIALOGX", Window )

The dialog never appears, because Window=MDICHILD and Parent=". The MDICHILD does not exist, and therefore it does not have a parent. I am guessing that @Window retains the name of the active window until Basic exits, even though the window has been closed and the system focus should have moved on. Has anyone else encountered this?

Gerald

[email protected]

Oystein,

My questions may seem like Tom Foolery, but you have revealed some nice insights in response.

1) RetVal=Dialog_Box( Dialog, Parent, InitParam )

I checked this within the event code, and Dialog and Parent were both assigned, hence the Hmm. I am convinced that this is part and parcel with calling the dialog from a subroutine from an OK button of a closed child window.

So I took your suggestion. When the OK button recognizes that the window being closed is part of an ongoing reentrant process, it passes a PROCESS event to the MDI frame for execution. Otherwise, it assumes that the calling routine will handle whatever comes next using the RET_VAL from END_DIALOG. This is working much better, and I thank you Oystein for your comments. But it does bring up another issue which has bothered me.

I create a custom event, say PROCESS, with parameters PROCESS, ACTION, and CREATEPARAM. I fire the event off with POST_EVENT( PROCESS, ACTION, CREATEPARAM ), where these parameters are program variables. I go to the MDI frame in form designer and add a quick event to call app*STPROCEXE**PROCESS. What allows the variable parameters of the event call to pass through to the parameters of the program call in the event? I can't seem to get this to work without writing a script for the quick event.

Gerald

Gerald,

What allows the variable parameters of the event call to pass through to the parameters of the program call in the event?

If I got you right - what you need to do is to fill in the Parameters field in the Quickevents window. You have a PROCESS event with three parameters. Therefore put the following string in the Parameters field:

'PROCESS','@SELF','@PARAM1','@PARAM2','@PARAM3'

Then let the stored procedure you call from the quickevent have five corresponding parameters:

function Process( Event, CtrlEntID, Process, Action, CreateParam )

I've never tried to make custom events. I just use OMNIEVENT. While you send or post

"PROCESS", Process, Action, CreateParam

I'd send or post

"OMNIEVENT", "PROCESS", Process, Action, CreateParam

Shouldn't make any difference. I just mention it in case there's some problem with custom events.

- Oystein -

Gerald,

(1)

RetVal=Dialog_Box( Dialog, Parent, InitParam )

You get a line 1 VNAV if Dialog or Parent is unassigned. I can't think of other reasons.

(2)

Did you get your first problem solved? I agree with Sprezzatura's advice, when they suggest letting the frame handle the dialog.

I think you might want to sit back and think through the roles and responsibilities of your components. In my experience it pays to look at the frame as a supreme master and MDI child windows as mere subordinates, with limited responsibilities. The frame is in charge and controls everything.

It's difficult to give exact advice when you haven't told what your post mortem dialog is about. But I get a feeling that what the dialog does is not the child's responsibility. I think the child should ask the frame to take care of that business.

I also think the child should not close itself, but leave that to the frame. All the child should do is to ask the frame to take care of the child's finishing business, and the frame, being in control, will know that this includes both closing the child and doing the dialog stuff.

Another point - in a well-developed app there will often be many ways of doing the same thing. There might be a button, a menu choice, a keyboard shortcut (accelerator), all doing the same thing. The menu item is on the frame. This frame menu item is a convenient nexus of communications and control. The Close button on the MDI child can send send or post a MENU event to that frame menu item. The accelerator belongs to the frame menu item. Everything goes through that frame menu item, and the menu item's handler does the actual work of closing the child.

Alternatively the child's Close button could use an OMNIEVENT to talk to the frame.

(3)

Why do you use End_Dialog to close a child window (see your first posting)? Isn't that for closing dialogs?

- Oystein -

Don,

I have confirmed that once the window in @Window is marked for destruction, both MDIFRAME and PARENT return null. Therefore I am saving the MDI frame name in a labeled common variable at the very start of this whole process, and using this when the frame is otherwise unknown. (I know it's a kludge, but I am desparate.)

This gets me to the very next problem, where a CLICK event script on a radio button ends a dialog box. This used to work, but now I am getting "DIALOG_BOX line 1, VNAV." Hmm.

Gerald

Tim,

Well of course I'm starting the window with a START_MDICHILD call, but closing it with an END_DIALOG. This is my attempt to get an input window to behave like a non-modal child window, but to return its values in the same way as a modal dialog would. Generally this does seem to work.

I have been told, but not by an authority, that Windows allows this. OI may introduce other reasons for not mixing these calls, but I don't know about that.

Gerald

Gerald,

I hope you understand I had to ask the question. You are, after all, closing a child window with an End_Dialog which goes against what the Help says to do.

Can you tell us exactly what you're trying to achieve and I'm sure someone here can come up with a solution…

Tim

Oystein,

Thank you very much. In programming, most things are obvious once you know the answer. I had tried just about everything ('PARAM1', PROCESS, "", etc.) to pass parameters through an event to a subroutine.

Needless to say, since @PARAM1 is not mentioned in the documentation, there is no way for me to guess that this would work. The greatest weakness of the OI product is the lack of accuracy and completeness in the documentation.

Gerald

Gerald,

The past few years I've done all my programming with quickevents calling commuter functions. I follow this rigid system with commuter functions named after my forms, and standardized parameter strings for the various events. (I have the parameters stored in a Word file and just copy and paste each time I need them.) I didn't exactly invent the method myself, but here's my tutorial on the subject. It might interest you: .

I think I made a later posting with more and updated events. You can find it if you search for Oystein and many event names. There are also postings by others with important contributions to the subject.

- Oystein -

There are very real technical reasons for why OI behaves as it does and why it would be difficult for it to do otherwise. In response to your query - no we've never run into this as a problem. The solution (if this is what you are looking for) is to either run/send/post an event to the MDI frame and from there run your subroutine, or try using the SYSTEM FOCUS property to derive the current window.

Of course in the words of that immortal punchline "now if we wanted to go there we wouldn't be starting from here".

The Sprezzatura Group

World Leaders in all things RevSoft

Or .. "If you don't know where you want to go, any road will take you there".

Don M.

Oystein,

Thanks. This thread showed how differing approaches to event management and parameter passing may address development issues. I have cut and pasted this information into a single document for reference. I would love see this published as a white paper or part of the documentation.

On the subject of your word document: instead, why not create an MDI_Child window with a bunch of push buttons, each button having its text property set to one of your strings? Then a common piece of event code on the form could put the button text into the windows clipboard when the button is clicked.

If OI had macro emulation, you could use a macro key to start the copy/paste process, followed by a single click in the child window to select the string. Seems like Sprezz was demonstrating just this sort of functionality in one of their postings a little while back.

Gerald

Gerald,

Seems that you are making this harder than it has to be (or I don't really understand what you are trying to do…or both.) Knowing what you now know, why don't you change your code to do this:

Window=Get_Property( @Window, "MDIFRAME" )

If Parent EQ "" Then Window=Get_Property( @Window, "PARENT" )

Result=Dialog_Box( "DIALOGX", Window )

[email protected]

SRP Computer Solutions, Inc.

Gerald,

Per the Programmer's Reference Guide regarding the DESTROY Service:

Used to destroy an object. DESTROY is used by End_Window() and End_Dialog. If Utility ('DESTROY') is called, the window will be flagged for destruction rather then actually destroyed.

I glean from this that your End_Dialog() call does not actually close your window entirely until all is clear, thus, @Window is still populated. This is good for you because if your MDIChild had truly closed then you would be encountering the problem of executing event code after the window that owns that event has been closed. This will give you error messages as well.

[email protected]

SRP Computer Solutions, Inc.

]

And if I was starting from here, I wouldn't go there!!!

Tim,

I am not so sure that closing a window with END_DIALOG goes against what the documentation says. The documentation is just not complete here, as elsewhere.

Gerald

Copied from the Online…

End_Dialog subroutine

Description

Use to close a dialog box created by Dialog_Box or Create_Dialog.

Syntax

End_Dialog(dialogname, result)

Parameters

The End_Dialog subroutine has the following parameters.

Parameter

Description

dialogname

Pass the name of the running window.

Result

Dialog procedures should be written so that any data needing to be returned to the calling window is returned in result.

Use End_Dialog to destroy your dialog window, and, optionally, to return a result to the caller.

See also

Create_Dialog(), Dialog_Box(), End_Window(), Set_Dialog_Info()

Gerald

In part you are right - that is, the core documentation would seem to have been lacking for a variety of reasons. I know that the present RevSoft Management is very keen to improve the documentation and have been supporting initiatives in this area. This documentaion overhall is being addressed by Ira Krakow ([email protected]) who is doing a fantastic job correcting, bringing together, supplementing and rewriting the on-line docs. As you might understand, this takes time and is helped by input by the RevSoft user community.

Having said that, there were several important documents on the core product which was published early in the OI's release - which appears to have past out of memory and or search of developers. Which is why developers, starting work on OI much later in its life, have been frustrated by the gaps in information.

Richard Bright

BrightIdeas New Zealand

[email protected]

Richard,

I appreciate your input. New developers should be relying on product documentation which is released with the product and therefore hopefully up-to-date, not old pass-me-down information which serves more to bemuse and confuse than to instruct due to to its heresay nature.

While I might be perceived as a complainer, I try to post my confusions with the documentation so that others can know what the weaknesses are. Of course I find answers elsewhere, but that is not the point. I should be finding answers in the documentation, and we both know that that is not happening … YET.

Gerald

Don,

Thanks. You've illuminated why the window is 'marked for destruction', as otherwise the event code on the OK button would have a problem. So really, the window can't quite go away until Basic does exit, but neither can it be treated as the active window.

Now of course I can try the system FOCUS property, and I also have to think about some other way to pass the window to subsequent routines, rather than relying on @Window.

Gerald

Of course another way to look at it is .. they are following the Microsoft model. Give enough docs to get the job done. But allow aftermarket people to write more. How many books are there on Access, Word or Excell .. wouldn't need all these books they had gotten it right

So, as you find this stuff sit down and write that book which will give newbees the info they need.

As for the Help .. as Richard indicated .. let Ira know if there is something wrong, incomplete or needed. You could help by writing it up with examples

[email protected]

DSigs Radio Free Oregon

Gerald,

Having the strings in a window with buttons to put them in the Windows clipboard sounds like a good idea. Hmm. I could even do it from my Word document with some macros.

- Oystein -

Absolutely agree - and understanding that you were keen to achieve excellent documentation - is why I point you in the direction of Ira. (I'm sure that he monitors the forum anyway, and is probably shaking his head in dispear and hiding behind behind a rock).

There was a period a while ago where the(previous) management (or parts thereof) were not to excited about product documentation - or so it seemed - even withholding it. Some methods got into the public domain only by the efforts of courageous insiders - often in response to personal enquiries. Thus we built up the tradition of OI secrets to be handed on only to the trusted. Am I over-exagerating, yes but you have the idea by now.

Anyway that is all changed with Mike Ruane, who knows that for RevSoft products to be properly appreciated, developers need to know how to use the product, and that requires in turn good documentation. Shaping up the documentation takes time - but in the space of 18 months it has come a long way.

Again would ask you - if you identify errors, or areas that need expansion, to bring it to the attention of Ira, who will be appreciative of the information.

BTW you should also checkout the authoritive work that Sprez have done in documenting of Arev (Revmedia publication) and OI (SENL and occasional papers).

Ricahrd Bright

View this thread on the forum...