Recent posts

Hi Timo,

That is basically what it does. Given the 'main' window handle it enumerates the controls, stores base values and the 'main' window size. Then upon WM_Size it uses that data and the percent change of the 'main' form applied to each control position/size parameters for a 'move' command. Nothing is stored upon a resize event so little overhead, only stored when init_resizer is used under WM_INITDIALOG.

John Z

#14

Work in progress / Re: New resizer discussion

Last post by TimoVJL - November 17, 2025, 12:26:41 PM

One idea is to put resizable control id list under first id
and collect startsize to an array of rects.
When window size change, count new coefficient and size controls with it.
This method might work with DWM too.
That idea have been used with control / button grids, like games.

#15

Feature requests / Re: RichEdit 4.1

Last post by Vortex - November 17, 2025, 12:21:36 PM

Hi Timo,

One of the Masm Forum members is using extensively the RichEDit control, maybe we can consult him.

#16

Work in progress / New resizer discussion

Last post by John Z - November 17, 2025, 12:01:10 PM

Resizing can be quite tedious -
I developed this resizing method for my Vcardz_i program https://forum.pellesc.de/index.php?topic=10191.0 which is resizing over 40 ontrols smoothly but that was hand coded control by control.

Now I've taken the concept and made it generic and 'automatic' suitable for a library and a header file or just two source files.

Attached are three small test files comparing the existing resizer and the new zsizer (temp name

)
Test demos for the existing resizer and the developing one:
resizerP_move.exe -> existing resizer.lib and header (all set to 'move',except toolbar to resize)
resizerP_resize.exe -> existing resizer.lib and header (all set to 'resize')
Zsizer_new.exe -> every thing resizes. however for demo one can set pushbuttons to move only, using the 'Toggle Button Size' as a demo.
This new resizer allows smaller than original which the existing resizer does not - to emulate original use the 'toggle Min Size' button as a demo.

So far the new method adds 9k to the exe (no optimization used yet) compared to the existing resizer.

This is not complete nor perfect so I'm looking for any inputs -
Right now there are three commands, I've not made it into a library yet -
extern int Init_Resizer(HANDLE win, int n);
extern void Form_Resize(HANDLE hwinmain, int num_window);
extern void Free_zsizer(void);

It does not access the control properties for Resizable Dialogs as I don't know how to get those settings.

Using it just involves two files zsizer.h, zresizer.c or one file and a library
Nothing is subclassed, but might need to. The resize method and calculation method would still work within the existing resizer framework I believe. (it's only math

)

Not every control is happy re-sizing - I don't know if it will work with 'Owner draw' controls yet either.

John Z

#17

Feature requests / Re: RichEdit 4.1

Last post by TimoVJL - November 17, 2025, 11:27:40 AM

If Rich-edit class "RichEdit50W" be option to Rich-edit 2.0 control, no new button needed.

#18

Feature requests / Re: RichEdit 4.1

Last post by John Z - November 16, 2025, 11:02:11 PM

Always good to maintain balance...

Maybe the TOOLTIPS_CLASS could balance the scales.

John Z

#19

Feature requests / Re: RichEdit 4.1

Last post by Pelle - November 16, 2025, 06:34:09 PM

I'm not sure how many new classic dialogs are created these days...
...but probably not a big thing, except I sure like to have an even number of buttons in the tool palette.

Also, unless officially deprecated -which I seriously doubt will happen- it's hard to just remove controls that have been there "forever"...

Possibly, but I will have to think about this...

#20

Chit-Chat / Re: WinDirStat

Last post by TimoVJL - November 15, 2025, 02:32:30 PM

That Everything works fine and was updated recently.

Pages 1 2 3 4 ... 10