Resizing different %gr areas in the same window

Quoted from LitusSaxonicum Dan, It is still a handle. Windows gives you a handle, you give Clearwin+ graphics a handle.

Due to either 'handle' word or design faults several people were unable to resolve simplest thing for a week. Of course this puts users away from Clearwin.

My question: why this handle was made this way as apposed to other handles? Why user has to be present here as a middleman? This confusion takes debug time and has no visible reasonability. Let's Windows set the value itself, do we miss with this anything?

Second, this bug would be easily found if Clearwin ALWAYS (with and without /undef or /checkmate) checked ALL input data on undefined status. Not doing this I find as a big design mistake. Nobody cares if GUI will be 1 microsecond slower. As probably everyone now knows well that FTN77/95 demonstrated that any compiler without checking for all undefined stuff is a pure garbage. Clearwin+ though decided to go against of its own ideology causing us a lot of lost debug time and itself the lost users base.

Dan

ClearWin+ could check if the identifier was 'undefined' but only in /UNDEF mode (or any mode that includes /UNDEF such as /CHECKMATE).

Another possibility, which might help, is to get ClearWin+ to generate a unique identifier when used with %gr or %pl and when the user-supplied value is less than or equal to zero.

John,

Using the middle of left icons, I get a mini caption bar (with the buttons) down at the bottom left of the parent window. Maybe you get that but can't see it (my monitor isn't 4k, but it's pretty big). I see it best if I maximise the main window to full screen.

A method to address this is to find the x,y size of the parent and reposition the child in its minimised state so that it is visible, but that would require actin when the minimise (etc) button is clicked, and I don't know how to do that. Perhaps it is encapsulated in the CLEARWIN_STRING@ 'RESIZE' in some way.

The example doesn't use %mi to specify a minimised icon, but even when you do, this stays on the caption bar of the child window, i.e. the window isn't reduced to an icon only (which is what I half expected) but still to the reduced size caption bar at the bottom of the MDI frame, although it does show the minimise icon on it.

What would be nice is for minimised child windows to be shown as %mi icons (if specified) in a row at the bottom of the MDI frame, complementing any status bar contents, but that is asking for a lot! I don't see any good reason why they should appear outside the MDI frame on the WIndows taskbar.

Eddie

Quoted from PaulLaidler Dan

ClearWin+ could check if the identifier was 'undefined' but only in /UNDEF mode (or any mode that includes /UNDEF such as /CHECKMATE).

Another possibility, which might help, is to get ClearWin+ to generate a unique identifier when used with %gr or %pl and when the user-supplied value is less than or equal to zero.

No doubts that for Clearwin to check for input undefined variables in /undef or /checkmate mode is most important. All other is optional.

As to %`gr 'not so handle' : if user is not that lazy and is not writing

i=winio@( '%`gr',5)

instead of
i=winio@( '%`gr',ihgrw) then switching to Windows defined real handles will not break any code. Not defining anything is the only bad thing. And even it may not break any codes if there is no need to switch windows like in above example for Rudnei. The specially issued warning may remind some lazy progger about using constant (5) instead of variable (ihgrw) is not permitted and if he refuses to comply then again the code will still work. Just look at the final code above for Rudnei: if you define those not so handles or Windows will do that itself with real handles the code will still work ok. But Clearwin+ logics tells that there is no visible reason for user to define %gr 'not so handles'.

How Windows is not crashing codes with user defined 'not so handles' if two instances of code are running ? 😃

I have made a note that the MDI needs further work. If you provide a menu bar then the immediate problem is resolved. When a main menu is not provided then the blank menu bar should not appear. Upon resizing the frame it would be nice if the child icons could be moved to the bottom of the frame.

I have made a note of this and I will report back if and when it is fixed.

Yes, this should now be fixed with FTN95 v8.40. Let me know if there are still problems.

I think that Robert has outlined our aims regarding the release date of the personal edition of FTN95 elsewhere on this forum. In exceptional circumstances a particular version may not appear as a personal edition but this is very rare.

The latest DLLs may not work with earlier versions of FTN95. Links to new DLLs are occasionally provided in relation to particular fixes. There are no plans to make this more organised.