SPINNER resize error

[archimede]

I made a Dialog with some spinners.
One spinner has the same control's position and size:
223,183,034,014...
If I resize the Dialog to full screen and, only for test, I use this command
DialogControlSet ( hDialogHandle, SpinnerName, @dcPOSITION, "223 183 034 014" )
the spinner is redrawed at the original position, but without the right arrows for selection... why?
It seem it is a WinBatch error.

[td]

It would seem to be an error in your script. There are no known issues with the Spinner control and changing the size and/or position. You do sometimes have to make sure that the control is redrawn after repositioning. There are multiple ways of doing this. My personal favorite is to use the UpdateWindow Win32 function.

[archimede]

I controlled the script and I am sure there are no amy error.
The same identical procedure works well for all other Controls, only with spinner works bad.
If, after zoomed dialog, I use
DialogControlSet ( hDialogHandle, "SP.TempoNelGiornoOre", @dcPOSITION, "223 183 034 014" )
it redraw the spinner bad, with the Space delimited list of a control's position and size are the *same* the original: if I no use that line that spinner is no redrawed and is showed well.
With a very complex procedure, after the diaog zoomed, I tried to change the original values and redrawed the dialog: it shows spinner well.
Another thing:
if I use
sPosition = sControlNewX : " " : sControlNewY : " " : sControlNewWidth : " " : sControlNewHeight
iTest = DialogControlSet ( hDialogHandle, sTestName, @dcPOSITION, sPosition )
sPosition2 = DialogControlGet ( hDialogHandle, sTestName, @dcPOSITION )

The result is:
iTest = 1
sPosition2 != sPosition

sPosition2 contain everytime the ORIGINAL position and size ( not the NEW position and size ): I think this is e WinBatch error.

[td]

Not all dialog controls are created equal. For example, the Spinner control is made up of two separate controls joined together. In our testing, the Spinner control works like other controls with regard to changing position when it is done correctly. Also, the Spinner is not the only control that may require a dialog redraw when resized. There are several difficult to anticipate factors that can lead to this requirement.

That said, if you believe it is some kind of "bug", so be i. That is your choice. 

There are multiple examples of moving WIL dialog controls in the Tech Database.  You can find them using the search term "resize dialog".

Also note that controls are sized in dialog units, not pixels. This means that the returned size of any control may not exactly match the set size because of representational errors induced by conversion from dialog units to logical units and back again.

[archimede]

Thank you very much.
I will search information about "resize dialog".

If there is only one Control that works differently from all other I think it is not very good for a language... This is the choice of WinBatch developers.

And about the DialogControlSet ( ... ) for set new position and DialogControlGet ( ... ) that no shows that change how is possible to solve that problem?

Thank you very much

[td]

Thank you very much.
I will search information about "resize dialog".

If there is only one Control that works differently from all other I think it is not very good for a language... This is the choice of WinBatch developers.

Anyone can make an assertion. As previously mentioned testing indicates that the Spinner control work just like other dialog controls.

And about the DialogControlSet ( ... ) for set new position and DialogControlGet ( ... ) that no shows that change how is possible to solve that problem?

DialogControlGet will not report a new control size until the resize is completed and in most cases that doesn't happen until processing returns from the user-defined callback function.

[archimede]

:-)
Then it seem like unuseful... and the manual no tell anything about it.
It is important to know if and how a control is set... when? When it is set, obviously...
:-)

[stanl]

I would suggest OP uploads test script where the control fails. Be happy to run it and test the original assertion.

[td]

:-)
Then it seem like unuseful... and the manual no tell anything about it.
It is important to know if and how a control is set... when? When it is set, obviously...
:-)

Since you are setting the size in the call to the callback your script already has the new size during that callback call.

[td]

I would suggest OP uploads test script where the control fails. Be happy to run it and test the original assertion.

It shouldn't need saying anymore but we always appreciate a minimal example that reproduces a problem.

[archimede]

Hallo.
To give a simple program example is very difficult because my program is big and to make a simple program is a long work.
Then I can explain you the problem with precision.

- Make a Dialog with WIL Dialog Editor; that Dialog must contain some different controlos AND one or much SPINNER control; in Dialog Attribute -> General -> Procedure set MainDialogEventManager
- Insert that dialog in the program
- in the program build the event manager function MainDialogEventManager ( ... )
  - in the @deINIT section set the active event for @deRESIZE event
  - at the @deINIT end set WinZoom ( ... ) for the Dialog window
  - in the @deRESIZE section set the factor resize reading new windows dimension
  - in the @deRESIZE section add the redraw cycle for all controls with old dimension * factor resize: at the end you will see all controls redrawed well, except for SPINNER controls.

Archimede

[td]

You don't need to provide your entire script. Write a simple script that does what you describe and only that. Make sure that it demonstrates your problem and post it here. It can't write it for you because as stated several times, testing shows that control sizing works as expected.