I'm wondering what the intended use is for the additional Options in the Dialog_Box() function

<3>If TRUE$ then disable ALL other windows owned by the OwnerID window, not just the OwnerID window itself.

<4>GETPARENTFRAME override. The Dialog_Box stored procedure uses the WINDOW object GETPARENTFRAME method internally. This option allows it to be tweaked as desired.

Could this be used, for example, to enable a generic toolbar on an MDI Frame while other MDI child windows are disabled? Similar to that discussed here.

Also, why <3> and <4>? What's <1> and <2>?

Cheers, M@

Vernon Systems

Hi M@,

The most accurate documentation for the Presentation Server is found on the RevDevX blog here:

 https://revdevx.com/documentation/

So I'd recommend looking there first in all cases (I know the current state of the documentation leaves a lot to be desired but that's something we'll be addressing in the coming months).

Dialog_Box is found in the "030 – Presentation Server Basic+ Interface.pdf" document.

GETPARENTFORM (renamed from GETPARENTFRAME, but that still works) is found in the "080 – Common GUI Object API.pdf" document.

So the <3> and <4> are incorrect (for whatever reason - I suspect it's one of those linked bullet-number issues that happens in Word). They should read <1> and <2>.

Options<1> is used to disable other forms "owned" by the parent (NOT direct child forms). Direct children are always disabled when their parent is disabled. This was introduced because we can now have Async dialogs that don't "hog" all the UI and let you do other things while they are running,

Options<2> is passed to the Flags parameter of the internal GETPARENTFORM call in Dialog_Box when it decides what the parent form is.

I'm not sure that it will help you with an MDI scenario as that's more a case of managing the enabled state of the various child windows which is outside the remit of dialog box. If there's a specific solution you have in mind then let me know and we can look at the best way forward.

Cheers

Carl

Carl Pates

The most accurate documentation for the Presentation Server is found on the RevDevX blog here:

 https://revdevx.com/documentation/

I'm not sure that it will help you with an MDI scenario as that's more a case of managing the enabled state of the various child windows which is outside the remit of dialog box. If there's a specific solution you have in mind then let me know and we can look at the best way forward.

Hi Carl,

Ahh, I forgot about the Documentation page on RevDevX - thanks!

We have a toolbar on an MDI frame with generic functions for any child window, that we would like to keep enabled. When a user initiates certain paths of action (windows that can invoke other windows), we disable other initiation paths (ie starting other windows, out of context) to keep the user on track without going off on a tangent. In OI9 we have implemented effectively synchronous MDI child 'dialogs' while keeping the MDI frame enabled and managing the enabled state of other child windows, as you say ;) . These dialogs are more like tools, that can return a result. So this involves yield loops to maintain synchronous behaviour.

A caveat is that yield loops in Basic+ can allow PS to process other events prematurely. In OI9 there is a way of avoiding this, utilised by Dialog_box(). But this particular method does not appear to work in OI10, or at least differently anyway.

It would be nice to rethink this design so it can be implemented better in OI10. I'm exploring better ways (hence the question). That would be a big job though and would significantly change the way the application works :/ .

Cheers, M@

Vernon Systems

View this thread on the Works forum...