Page 1 of 1

Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Thu, 19 May 2005 2:29:13 GMT

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Thu, 19 May 2005 2:33:09 GMT

I didn't know that an inserted image would appear like that.

Here is the "GUI diagram" jpeg as an attachment instead.

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Robert >> Thu, 19 May 2005 4:04:01 GMT

Does the user see the working form as a 'window', i.e. with control box, title bar, etc (which could be very cluttered), or is it a 'panel' within it's parent (stack x). I was wondering if you can use docking containers to implement the working form(s), and 'stack ' would either be an mdi child, or would have a parent relationship (using setFormParent) with the Master Parent.

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Thu, 19 May 2005 21:33:06 GMT

There would only be one title bar per stack. However the stacks would overlap.

Currently these stacks are full screen and navigation between them is through their taskbar button. I use setFormParent at the moment, which works fine because the Working Form cannot be moved, nor can the Stack (as it is maximised).

The only way I've found to achieve this is using a lot of manual management code, e.g. preventing the working form from being moved, auto moving all working forms when the stack is moved, minimised, etc... But this is what I'm trying to get away from.

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Robert >> Fri, 20 May 2005 4:31:22 GMT

Must the working forms be implemented as individual forms?

If they are implemented as controls on the stack form (e.g. using frames, pictures, docking controls), then the o/s will manage movement, minimising, clipping, etc.

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Tue, 24 May 2005 3:18:53 GMT

Perhaps I should have mentioned that I'm re-working the gui for a mature system that contains over 500 forms.

I've tried creating the Stacks as MDIFrame's however new working forms will only open on the most recently created Stack, as each stack is an instance of the same Form class. Perhaps there is a way to control this.

My preference is to create the Master Parent as the MDIFrame, the Stacks as mdiChildren, and then use setFormParent on the working forms to keep then on top of their Stack (holder). However the zOrder causes every Stack form to be painted under all Working forms, so dragging one stack over another causes the Working form of the lower stack to be painted in front of the Stack on top.

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by T Moore >> Wed, 25 May 2005 8:12:09 GMT

You may find that life may get easier if you remove the border and title bar for the forms in each stack and set their parent to be an empty MDI child form. Each form in the stack would have the previous form as its parent. It would be relatively easy to code a move event of the MDI child to move / resize its children.

When a new form is opened in the stack, have you tried to hide the previous form and control the forms in the stack via a FormArray? I seem to remember that you can't hide an MDI child form, but you could move it outside the visible part of the MDIFrame. If the forms in the stack were not MDI children then this might be easier to work with.

Torrie

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Thu, 26 May 2005 4:59:48 GMT

Hi Torrie,

You actually know more about the current GUI design than you may have realised, I'm re-working Concord which was originally put together in a similar way to the CMS.

How are you going anyway? Still way over the other side of the world?

Your idea is pretty close to what I'm looking at at the moment. I have removed all the manual skinning, and added borders and title bars to all our dialog forms. If you remember we have an SDI MainMenu that consumes the whole desktop area and can't be moved or resized, the Stack Parent is the same, and the child forms sit in the middle of the stack parent. No form's could be moved or resized.

I want to make the MainMenu the common backdrop to all Concord Stacks, ultimately as an MDI frame so that Stacks (mdi children) can be shifted off screen and scrolled to if need be. Also so the app has only one button on the taskbar. I'm planning on making the Stack form a controlling form that is always obscured by its children, and therefore want the child forms to have borders and a title bar. The child forms would be attached to the Stack through setFormParent. I would then use the formMove event to ensure the stack moves around with the child.

Here are the 3 problems:

1. The child form is painted over top of the MDI Frame scroll bars. Also if the MDI Frame is not full screen, the child forms can be dragged right outside the frame (I'm sure I could stop this though).

2. The Stack re-positioning code I have in the formMove event of the child form produces odd left and top positions???
child.windowToScreen(x, y);
stack.screenToWindow (x, y);
stack.move (x, y, stack.width, stack.height);

3. I need a way of re-positioning the child form if the MDI Frames scroll bars are used to shift/slide the client area.

Any ideas or suggestions?

Re: Underlying GUI design/structure

Posted: Fri Aug 07, 2009 12:49 pm
by ConvertFromOldNGs
by Andrew >> Thu, 26 May 2005 5:31:32 GMT

If I forget about mdi forms altogether, then the only issue I have is that when the Master background is restored from a maximised state the stacks and their children can still be sitting outside of it's borders.

It's really only in this non-maximised state that I need the scroll bars.