AutoHotkey Community

Then the name IsFunc would be a bit misleading. Could we use the & (address of) operator with function names? It can conflict with variable addresses, though, because the same name can refer to a function, a label and a variable. Maybe a better name for IsFunc() is the best, like Address() or FuncAddr()…

That is why it returns a boolean value at the moment. OTOH, I think IsFunc returning a function pointer is comparable to WinExist returning a window handle. Does anyone else have naming suggestions?
Not without reserving function names. One idea I have is to create a variable for each function, essentially reserving the name. Dynamic function calls could then be extended to call by reference, avoiding a name lookup.

I intend to re-implement more LowLevel functions, since they can be implemented more easily, efficiently, reliably, etc. from the C++ side of AutoHotkey, but it is low on my list of priorities.

Progress: the debugging features are minimally functional. breakpoint_set, run, step_into, step_over, step_out and stop are supported (see DBGP.)


[XDebugClient with added AutoHotkey syntax-highlighting.]

the DBGP debugging features above are really great and i can't wait until they are implemented, but a lot of times all i need to see are the line listings, which sometimes i can't becuase of timers and loops

wouldn't this be easy to implement?

I keep an eye on the Wish List forum, so it is no surprise I had already seen your three existing threads (1, 2, 3). I would prefer feature wishes be kept in the Wish List forum, separate from this thread, unless they relate directly to a feature I have implemented or plan to implement.

If I see an idea in Wish List that interests me, I will consider implementing it. (For instance, Optimized DllCall().)

Thank you for this! This is going to come in very handy..

_________________
.o0[ corey ]0o.

Hi Lexikos,
I think, you've done a great job. It's fantastic. Can I also compile a script with your adaptions? And if so, how do I manage it?

_________________
Greetings
Rog

Rename your old autohotkeySC.bin and replace it with lexicos's. You will then be able to compile using the normal compiler.

_________________
Steve F AKA Superfraggle

http://r.yuwie.com/superfraggle

Thanks a lot. Life can be so easy, when you know, what you do.

_________________
Greetings
Rog

problem: use hotkey to replace AltTab ignores #if condition

Hi Lexikos,

I've got a little problem with your fantastic and long time expected #If. I use it basically with the function MouseIsOver and normally it works very well.

My problem is: I have one script running the whole day with my all-day-long-hotkeys. One of these is MButton:: with different #If MouseIsOver actions depending on different applications. But these MButton-hotkeys stop working, when I start another script with additional MButton-hotkeys triggered by #If MouseIsOver for a very special application.

With ListLines I can see, that all #If MouseIsOver-functions of script 2 are executed without success (which is correct). But afterwards the MButton-Hotkeys of script 1 aren't executed any more.

With #IfWinActive these problems never occured, so I'm hopefull, that this is only a bug which can be solved quickly. Thanks for this.

_________________
Greetings
Rog

Hi Lexikos,

I'm afraid, I found another bug. When I compile a script with Ahk2Exe.exe and your AutoHotkeySC.bin and the noDecompile-parameter, I get the errormessage when I start the compiled exe.

I would love, to get this solved as well. Thanks.

This is normal behaviour.

I am unable to reproduce this. Perhaps there is more to your scripts than mine:
Note that if the (iirc) most recently loaded script handles the hotkey (because the #if expression evaluates to true), the other script will not consider executing the hotkey, so will not need to evaluate the #if expression.
There is an easy solution - don't use NoDecompile.

Compiling AutoHotkey from fresh v1.0.47.06 source in Visual C++ 2008 gives the same result. I can think of two possibilities:

1. An obscure quirk of Visual C++ 2008, a difference between 2008 and 2003, or a side-effect of the project conversion process prevents NoDecompile from "working" correctly. (Chris uses Visual C++ 2003.) This could be confirmed by anyone with access to Visual C++ 2003.
2. NoDecompile functionality has been removed from the public source code to prevent exploitation. I would not expect this to be the case; however, it is apparent that the public source code of Ahk2Exe "handles" the /NoDecompile flag, but does not actually do anything with it.

Well, you're right. I had a #If (only) section with a MButton & Wheelup::-Hotkey in the most recently loaded script. And this Hotkey already prevents the execution of the mbutton::-Hotkey through the second script, even if it fails (because I only press MButton).

When I delete the MButton & WheelUp::-Hotkey, everything works fine. I can live with it.

Oh, so easy? I'm sure, I'm able to do this

Thank you very much.

_________________
Greetings
Rog