AutoHotkey Community

[PhiLho]

[EDIT] numEric provided a much better version, which is referenced in the manual now. See Radio button to control number of loops and msgbox text for some reasons why it is better.
I left this because some techniques here can be interesting.

Recently, Torteth asked for more flexibility for the UpDown GUI control.
I came with a workaround that seems to be usable, but was hard-coded.

I tried to add a bit of flexibility and code-reuse.

There are still some constraints and limitations:

- These special controls must be created before any other Edit control. This limitation could be removed if we knew the ClassNN of a newly added control. Perhaps it is already possible.
[EDIT] I found how to remove this restriction! Yeah!

- I coded this only for the main GUI (no GUI number). Not a big problem, I think.

- The user can change the value to one that cannot be reached with the control. Eg., in my example, using the arrows you can get only even numbers, but if the user types an odd number, the progress will then go from one odd number to the next.
This can be actually an advantage, and it is easy to add, if necessary, code to check if the value is valid, otherwise to constrain it to legal values only.
Note that with a small hack, you can associate two up-down controls to an edit one, eg. one for coarse values, the other for finer values.

Here is the code, with a small example:

[foom]

Hi philho,

Torteths thread caught my attention too since i am developing and frontend for H.264 encoding and would like to have updown controls which output floats since some of the commandline params the frontend passes to x264.exe are floats.

I apreciate your work on this but still think that this is a bunch of code and i think i might have and solution which would be easier to maintain.
Problem is that it demands to work with structures.
Now youre one of ahk's bitjugglers and might tell me whats wrong with following code

Edit:
Found the error and reworked the script. Here you go.

[PhiLho]

I like your way, it is good to have an alternative.

The good points:
- The controls are created in the classical way, using buddy.
- The code is indeed slightly clearer -- but of same size (if you remove the demo code in both versions).

The bad points:
- You still have to know in advance the classNN of the added controls... It is doable in GUIs, but not very friendly. Of course, it is more a limitation of AHK than a problem with your code.
- More annoying, but I suppose you can correct this: if you use the Up and Down keys in the edit control, as requested, the progress will still be 1 by 1, and starting at the initial default value...
- You parse the settings each time. I avoided this by putting them in arrays, at the cost of convoluted names... And frankly, the time spent on parsing is probably unoticeable.
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[foom]

[PhiLho]

I think that the problem is with the mysterious (undocumented) SendMessage 0x46A.
Either it fails and errorlevel is 0 and you return false (that's what I see with WinInspector), or the GetudData fails for the same result.
_________________
vPhiLho := RegExReplace("Philippe Lhoste", "^(\w{3})\w*\s+\b(\w{3})\w*$", "$1$2")

[foom]

[PhiLho]

[foom]

Maybe Chris borked something with the last update...he did somethink to fix an onmessage bug. I found another bug with onmessage. See here