AutoHotkey Community

@Chris: You have added a Glabel to the Edit-Control, that is
called if a change was made to the edit-content. So in DELPHI
this is an on_change_event.

Now my problem: Assume I want the User to enter Floats in an
Edit-Control. That means only +-.0123456789 are allowed chars.

E.G I must check, if the "+-" is entered at the beginning of the float
or where the . (dot) was entered, or if there is already a dot in the float.
In Delphi I do this with something like on_key_event. The Key is NOT YET SHOWN in the edit-control !!

Then I check WHAT KEY was pressed and WHERE the Input-Cursor was
and react on that. Assume the - (minus) was pressed somewhere within
the input (Cursorpos>1) then I send a beep and do nothing, but if
the Minus-key was pressed at Cursorposition 1 (and there is not yet a
Minus), I can allow it and place it in the edit at Position 1.

I thougt about something like that (pseudocode):


1: I thought about a new parameter that allows to set the allowed
characters for the edit (see above). This is not necessary if the points below are implemented, because the checking for
valid keys can be done totaly within the called G-Label.

2: I need a way to know at what position in the edit-control the cursor
is. If I am right there was a way but have forgotton how to do it. So
I thought about a internal variable like A_EditPos that holds
the position of the cursor. May be A_EditRow A_EditCol are better.

3: The G-Label should react BEFORE the edit is updated, so that
the the key is NOT YET visible in the edit, but the pressed KEY is stored
in a internal variable like A_Editchar. This means, if the user
presses a Key in an edit-control the KEY is stored (BUT NOT YET SHOWN)
and then the Glabel is called.

If we put this together it would be easy to build clever Edit-controls that
allowes various even formatted input like MM.DD.YYYY.

This also would allow the USER easily to react on special-keys like
RETURN.
E.G. he can jump to another control if the User pressed RETURN in the
Edit-Control, or he even can react on ESC, TAB or anything else.

So the only changes that should be made are:
Glabel is called AFTER any Keypress BUT THE KEY IS NOT YET SHOWN
in the edit-control. It only is stored in an a new internal variable.

If I am right, this will NOT break any existing scripts, because the glabel
for edit-controls is quite NEW, but it would greatly enhance the use of
the edit-control. This means, if a Glabel is used for the edit-control that
NO KEY is ever shown in the edit-field, until the USER decides what
should be done with that key.

[Edit:] If you don't want to break the existing use of the glabel (Char is
shown first AND THEN Glabel is called), maybe it is possible to add a
new parameter (e.G OnKeyEvent or NotShowKey) that can toggle this bevavior.

I hope this is not again one of my many bad ideas.
I think this is really a quite good idea.

_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

@Rubberduck : I'm perfectly agree with you. This improvement of the edit control would allow to programm a masked edit control, as I asked for in the Masked edit control in GUI topic. I'm so also agree with your proposition of the internal A_EditPos & A_Editchar variables.

@Chris : If it's possible to do that for the edit control, may it can be done for others controls in witch it can be usefull, for example in DateTime, & DropDownList

I agree, it could be useful. Your example of key entry restrictions is followed by some commercial programs. But I hate it. If I enter a number, and realize that there was a wrong decimal point earlier, I cannot enter the right one where the cursor is and go back later to erase the wrong point. I have to first go erase the wrong point and than go back where I was to enter the right one. I prefer to be able to enter whatever mess I wish, and fix it before I submit the field. Especially, if data is pasted, too. Also, two '-' signs are allowed: -3e-6. The second one can be anywhere, but immediately after an 'e' or 'E' or whatever you choose for designating the exponent. You need a quite complex finite state machine to do an on-line syntax check.

I am really happy that at least one time I seem to have a good idea.

If my ideas are implemented, I will write some functions for
different input-things (float-input, integer-input, date-input...)

A short update to my idea: ANY Key that is pressed should be stored in the internal variable also Keys like CursorRight.

If there are Key-combinations like CTRL-CursorRight maybe they
could also be stored in the internal variable, maybe in a delimited-string like "CTRL|CursorRight", but of course in AHK-Hotkey-Syntax.

===================================
I have thrown a look in the AHK-Todo-List. There is a point

-Support for moving the caret in an Edit control, and optionally selecting part of the text (if possible).

Moving the caret would be obsolet, if the User can handle it by himself
by reacting on Keys like Cursor-Movement or Ctrl-Right (Word-jumping).

The idea of selecting partial text in the edit is quite good, but then it
should be easy not only to select text, but also receive if there is already
a selected text, maybe with internal variables like
A_EditSelStart, A_EditSelEnd (I know those from Delphi).

_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

This could be done but it would be fairly complex because there is no built-in OS notification for this. Thus, it's complexity makes it a fairly low priority for now. You could get almost the same effect with something like:

Use ControlGet to get the row/column of the caret as well as the selected text in an Edit.

That's a good idea. There is already a plan to have a GuiClick label that would allow the script to be notified of every mouse click inside the window. A GuiKeystroke label would be a logical counterpart.

I checked but there doesn't seem to be any built-in way to do it for DateTime or DropDownList. It could be done manually but would need quite a bit more code.

Thanks for the ideas.

I really thought this was a goog idea
Sorry, never posting any idea again

_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

The idea is good but notifying the script after the text has changed is sometimes (perhaps even most of the time) more desirable than doing it beforehand. Further evidence of this is that the OS provides no built-in means to do pre-notification but does offer post-notification.

It's also a question of complexity. Since code size and development time are limited resources, a feeble effort is made to conserve them by prioritizing based on cost+benefit.

Again I say "If it is so, then it is so"

I assume DELHPI is using its own controls that allows much more
control over the controls and there events.

Sorry, but I again and again try to improve AHK, and I only know what
I can do with DELPHI (this is my programming-background).

It was really easy for me to program any formatted or masked input
in Delphi by reacting on input before it is shown, and so I thought
this would really be useful for AHK, because it would be easy to do
nearly every Input-Thing a User might want to implement.

Your code-snippet

is not much help to detect if a plus or minus is input at the right place.
I tried some walkarounds that works better but I always get
some sort of flicker (+ placed wrong, remove from edit-text, send
changed edit-text back to edit-control).

I also tried to define a lot of Hotkeys (+-.0123456789) and react on
them. Maybe if I now succeed in getting the current cursor-position
in the edit-field I can do a flickerfree walkaround.

You have written:
Use ControlGet to get the row/column of the caret as well as the selected text in an Edit.

If you have time please give me a little precise script-example, on how to
get the current cursor-position in the editfield. I know you now say "Can
this idiot not read the Helpfile", but the helpfile is a mess (to be somewhat
hard). Should a USER be forced to read each line of the help-File or do
a hour-lasting search on the forum [often without success] to solve a
little problem. Of course anybody can post a question to the forum and
get an answer, but shouldn't it be, that the normal helpfile should
answer MOST questions. Wouldn't you be happy if the SCRIPT-Section
of your AHK-Page would be much bigger than the HELP/Support-Section?

Thats, why I started my AHK-Howto (and stopped it because of lacking
interest, at least that was my feeling). AGU was the only that gave
me some encourage to go on with it.

There really should be a Forum-Wide discussion where AHK is going.
Adding a DLL-Call is fun, but the average User does not even know
how to handle this ("I know DLL's, but what DLL do I need, and what
functions can I call, and how do I call them, and how do I receive result").
On the other hand you said in some post "the average user will not use
this or that, so it is low priority". Is it low priority that a user (like me)
is not able to allow the script-user to enter a float, without flicker. Is
it low priority that GUI,Color is not working bugfree with sliders? Is it
low priority that placing controls precise on a Tab-Control is not
possible?

What is the priority of a program? That the User can easily understand
and use the implemented functions, or that he is forced to find
workarounds to get the program do what he wants?

I only wanted to write a GUI for my BigInteger-Script (I wanted to
update it for Big-Floats) so the user can enter a float. It is not possible.
Do I want to much? I have looked at some AHK-reviews and some
threads about AHK on other forums. Often you find the advice
"Only for advanced users!". Why?

Doing a

is easy, but if you want a little more you are trapped.

All ideas I posted have been simple ideas, and everytime the answer
was "Low priority" or "Hard to do" or "use DLL-Call" or "will break
existing scripts". Some day you will be forced to go to BETA-State
and BREAK existing scripts. I know it, you know it.
Is it better to think about things now, clear up things, define a direction
where AHK will go, what it will be. Thinking about this now, or be like a
lemming, some day standing before a high cliff not knowing what to do?

Sorry, but I am a little upset now (I will calm down again)
and there is a great chance that I am wrong, but I think there are a lot
things going wrong with AHK.

_________________
Wer keine Antworten hat muss nicht dumm sein,
dumm ist nur der welcher keine Fragen hat.

If you can give more specific details about deficiencies in the help file, I'd appreciate them. For example, some of the older commands like ControlGet should probably be overhauled to give an example for each sub-command (like the GUI command does for each control type).

That's probably not realistic. But I would hope that over time there will be fewer support questions to the extent that people search the forum to see if their question has already been answered.

In my experience, for every one reply you get, there are 10 to 100 other interested users who are too busy to reply or feel they have nothing noteworthy to add. You could try setting up a poll in the future, which is probably a better way to guage interest. Even then, 80% or more of the forum's visitor's are probably guests who won't be able to vote.

Different users have different priorities. I'm by no means objective either, but I try to be realistic about cost vs. benefit in terms of percentage of users vs. code size. I'd welcome polls or contrary opinions about how priorities should be set. Perhaps a poll should be set up with no more than 7 choices about what major aspect of AutoHotkey development should be given top priority: Hotstrings, hotkeys, GUI features, syntax improvements, etc.

If there were an easy way to fix it I would. But it appears to be a built-in limitation of the control itself. The control can be changed but the amount of effort and code involved is higher. It seemed like that time could be better spent on adding new control types such as ListView.

I'd welcome more details about deficiencies you see here.

You have to admit that very few users would benefit from having integers bigger than 9223372036854775808. And since it would hurt performance, it seems best not to have it as a built-in feature.

People who are used to GUI interfaces for setting up hotkeys would probably consider AutoHotkey too advanced, especially if they didn't have the patience to glance at the Quick-start Tutorial.

I thought it was better to be honest. Despite my efforts at being accurate about estimates, there are probably 50 posts on the forum containing overdue deadlines or feature requests that have fallen by the wayside.

The central missions of AutoHotkey are automation and hotkeys. Things like GUI and hotstrings are slightly lesser. Also, maintaining compatibility with existing scripts is a very high priority, at least until such time as there is an AutoHotkey 2.0 (which might never happen; it depends largely on user interest -- possibly gauged via poll).

To the extent you have time and patience, please continue to post specifics whenever you think of them.

I don't want to intrude on your little nervous breakdown, Rubberduck, but I'm sorry to say that in my view your last post, besides being somewhat rude and ungrateful, showed a complete lack of perspective on your part. Are you actually complaining angrily to the hard-working author of a free program about his priorities? ... and practically demanding a vote on its future and direction?? We New Yorkers call that chutzpah!

I hope Chris never makes the mistake of turning his project into a democracy, and the price he charges for AutoHotkey is his guarantee that he never should have to. Despite its obvious and undeniable usefulness to so many of us, AutoHotkey is fundamentally an act of individual artistic creation on the part of one person who, even if he does so frequently accept suggestions, recommendations and even requests, must remain the ultimate judge of what new features and improvements he deems worthy of his time, effort, interest and, yes, vision. [For further information on this concept, please see Ayn Rand's "The Fountainhead" ]

If it will help put your mind at ease, I can tell you as somebody who has some familiarity with the Windows API that whenever I've read Chris say that some idea would be "hard to do" or would increase the AHK code size too much, he was telling the absoute truth (and he has usually followed up the statement with something along the lines of " ... but if you know of a simple way to do it, please let me know").

Please don't stop posting your ideas, ... really! But as the sign on the wall in old Far West saloons used to say, "Please don't shoot the piano player!"

Later,

Jacques.