Forums

by Andrew >> Tue, 21 Jun 2005 0:41:40 GMT

I have a non MDI child window that is skinned and uses the standard Window maximise button.

I'd like to be able to override the default maximise behaviour, here's an example of the maximise event I'd use if such an event existed:

windowMaximised () updating;

vars
iLeft, iTop, iWidth, iHeight : Integer;begin

getDeskTopWorkArea(iLeft, iTop, iWidth, iHeight);
self.windowState = WindowState_Normal
self.move (0, 50, iWidth, iHeight);
end

Any ideas?

by Jade Support >> Tue, 21 Jun 2005 1:08:50 GMT

What about tapping into the resize() event method, as below?

resize() updating;
vars
iLeft, iTop, iWidth, iHeight : Integer;begin

if self.windowState = Form.WindowState_Maximized then
getDeskTopWorkArea(iLeft, iTop, iWidth, iHeight);
self.windowState := WindowState_Normal;
self.move (0, 50, iWidth, iHeight);
endif;
end;

Jade Support.

by Andrew >> Tue, 21 Jun 2005 8:50:08 GMT

I appreciate the feedback, while it achieves the result it makes the window look like it's being snapped back from a fully maximised state.

I'm currently using the formMove event for a similar task, which has a less visible flicker when the top position is overridden.

A better description of what I'm ultimately looking for would be a "maxButtonClicked" event.

Thanks,
Andrew

by Patwos >> Tue, 21 Jun 2005 5:34:19 GMT

I have to ask the obvious question, why would you want to prevent the end user from truly maximising their form if that is what they want to do?

I personally find it frustrating when applications deliberately interfere with "standard" behaviour - or at least expected behaviour. For example, older versions of Adobe Reader used to trap the Shift+Home and Shift+End keystrokes on the search form and stop the TextBox from highlighting all the text. I realise Adobe Reader started on Mac's where Shift+Home and Shift+End doesn't select the text in this manner, but did they really feel the need to impose that on Windows users?

Pat.

by Andrew >> Tue, 21 Jun 2005 8:44:42 GMT

Pat,

I appreciate your concerns for the potential frustration of our users - however you can rest assured that the result of this altered behaviour is exactly what a Windows user would expect.

A maximised window does not always fill the entire desktop area, for example an mdi child window.

Mdi windows have several disadvantages that can be overcome by managing the window behaviour manually. The interfering we are doing here actually ensures that the user interface conforms more closely to the windows standards users have come to expect.

Andrew

by Jade Support >> Wed, 22 Jun 2005 4:43:15 GMT

Presumably there's a way to 'reset' the desktop dimensions to fool applications into doing the behaviour you desire. Take for example one of those 'Earn cash while surfing' banners. The banner application runs along the top or bottom of the desktop in similar dimensions to the space left by your example code. No other application can be maximised over it (they can be dragged over). This suggests there is a way to redefine what value constitutes the 'top' (or bottom) of the desktop so any other application, when maximised won't obsure it from being visible.

Jade Support.

by Patwos >> Wed, 22 Jun 2005 4:45:42 GMT

Ah yes...... the joys of a simulated MDI. I remember having to take a similar approach back in the Jade 5.1 days with a "Juiced" application - including simulating the Window menu, handling Ctrl+F6 and Ctrl+Shift+F6 to swap around the simulated MID Child windows etc.

Since 6.0 days though I have come over to the dark side and now always work with MDI forms..... I have to admit, with the enhanced skins in Jade 6.0 and the new parentAspect settings, I actually find that MDI works very well for my desired look and feel without all the complications of the previous interface design and manual coding of things such as resize logic. It certainly makes designing new forms a breeze when you don't have to write a single line of resize code anymore. )

Pat.