Menu items on MDIFrame .. not on window? (OpenInsight 64-bit)
At 07 MAR 2020 02:08:11PM Dave Sigafoos wrote:
In 9.x and before the menus would go to the MDIFrame and not be on the specific window. Is that still an option (i can't find it) or has that been removed?
At 07 MAR 2020 02:22PM Andrew McAuley wrote:
Just checking that you are starting an MDI child not just starting a window?
World leaders in all things RevSoft
At 07 MAR 2020 05:57PM Dave Sigafoos wrote:
Yep .. start an mdi frame then a mdichild
At 07 MAR 2020 10:35PM Richard Bright wrote:
Hi Dave,
While not addressing your query - imo the OIv10 design is light-years better. The old concept of parent frame 'inheriting' the child-form menu, I believe was a product of the early Windows metaphor and the likes of MS Word where you launched documents into the encapsulating frame. We thus had a debate of MDI v SDI design and pushed designer into constructing side menus or floating button panels if they wanted the encapsulating frame. I like each form to be able to have its own unique menu appropriate for its functioning; just never made sense that the parent frame menu should change as focus shifts from one form to another contained in the application frame and the OIv10 design is much more appropriate where we have multiple forms within the frame and multiple applications running on the desktop.
Richard Bright
At 08 MAR 2020 01:20PM Dave Sigafoos wrote:
Thanks Richard … i guess that gives me the WHY :smile: Just trying to track down all the things that are not working as .. and seeing if it is my system or OI10 as should be.
Dsig
At 08 MAR 2020 08:39PM Donald Bakke wrote:
I'm a bit confused about the reference to OI 10 being "light-years better". Is this referring to OI 10's use of the MDI frame or OI 10's implementation of MDI for developers? I'm guessing the former since OI 10 is an MDI frame but it does not swap out the menu bar when MDI children are activated.
FWIW, we've been long time adopters of MDI frame applications but have never built MDI children with menus. It isn't so much that we minded the context switching (more on that later), but it meant that we would have to duplicate all common menus across all MDI children. If there was a way to create a default menu in the MDI frame and the MDI children would only add to this menu, we might have taken advantage of this from time to time.
Context switching is always happening one way or another. Even the most modern UI employing the Ribbon Bar control will adjust based on the current document or the state of an action within a document. OI 10 does context switching via the context-menu that displays in the Tab bar.
At 08 MAR 2020 10:23PM Barry Stevens wrote:
Don,
OI 10 does context switching via the context-menu that displays in the Tab bar.Are you referring to a new developer function in the MDI Frame - > MDI child setup/running. Please explain if so.
At 08 MAR 2020 10:23PM Richard Bright wrote:
Hi Don
Perhaps my "light-years better" was more a reflection of my pleasure it at last being able to use a master menu that didn't get over-written by the child form in current focus.
Many of my forms have custom menu items specific to the respective form. Yes, most forms have a generic layout - but customisation of menu elements for specific form needs is important to me. I certainly go along with your comments - "If there was a way to create a default menu in the MDI frame and the MDI children would only add to this menu, we might have taken advantage of this from time to time."
The OIv10 menu setup as it now is allows me to have a master frame menu - launching forms etc, a slider for application wide form DPI scaling plus the context sensitive panel. These are all great improvements from my original OIv9 SDI platform.
Richard
At 08 MAR 2020 10:59PM Donald Bakke wrote:
Are you referring to a new developer function in the MDI Frame - > MDI child setup/running. Please explain if so.
No. I'm referring to the way the OI 10 IDE is designed.
At 09 MAR 2020 06:25AM Carl Pates wrote:
Just to jump in here - the fact that MDI frame menus are not replaced by their children is officially a bug, but I'll I fix it so that children retaining their own menus is left as an option so you can choose how you want your apps to be designed.
The ability of MDI children to retain their own menus stems from the fact that menu bars are no longer actual menu bars - they are toolbars with buttons drawn to look like menu items. We had to do this so that the Form Designer could display a form with a menu, as Windows limits menu bars to top-level windows and we couldn't display one for an anchored form at design time.