I did test the code but had a look at it.
Is there a reason you do not use switch/case? I saw if/else chains that IMHO would be suited for switch/case.
Also the whole script is just one file. It made it harder for me to understand the flow of the script.
Both cases are mainly subjective issues, but if you consider them it might help to attract others to help.
If I understand correctly this script has to be run with a AHK v2 executable, right?
CallTipsForAll v2 - 2020/07/31 - a121
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
@toralf
Yep AHK v2 (for all the latest features).
I have been thinking about splitting up the code as you suggested, that will probably be my next update.
Any comment on how it functions? Comments about the call tip display? Settings dialog?
EDIT: As for switch/case, I just haven't been in the habit of using it yet...
Yep AHK v2 (for all the latest features).
I have been thinking about splitting up the code as you suggested, that will probably be my next update.
Any comment on how it functions? Comments about the call tip display? Settings dialog?
EDIT: As for switch/case, I just haven't been in the habit of using it yet...
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
@toralf
What kind of "cmd line" or other method did you have in mind for changing / setting the base file?
I'm currently working on a way to make changing the base file more accessible than just through the tray icon.
In my script, the base file only needs to be set in Settings["BaseFile"], and then to call ReParseText().
What kind of "cmd line" or other method did you have in mind for changing / setting the base file?
I'm currently working on a way to make changing the base file more accessible than just through the tray icon.
In my script, the base file only needs to be set in Settings["BaseFile"], and then to call ReParseText().
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
I would love the script to accept a cmd line parameter (e.g. base) that can be used to set the main file to be parsed. Then I could kill the old script when the user changes projects and start the script with a new base file, which in AHK project manager is called main file.
ciao
toralf
toralf
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
I haven’t used v2 yet, what are the latest features that were beneficial for this script?
ciao
toralf
toralf
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
@toralf
By "latest features" i only mean that I haven't made the v1 script match the v2 script functionality yet. That will take me some more time.
Currently the v2 script can process #INCLUDES, libraries, and classes, and display calltips across all files loaded from #INCLUDES and libraries.
I plan to bring these functions to the v1 script as well, but i need more time to test and work out bugs in the v2 script before i do that.
EDIT: As for command line parameters, I could develop that, but wouldn't it be easier to just use this script as an #INCLUDE and populate the Settings object directly? Then call ReParseText(). Wouldn't that be easier?
By "latest features" i only mean that I haven't made the v1 script match the v2 script functionality yet. That will take me some more time.
Currently the v2 script can process #INCLUDES, libraries, and classes, and display calltips across all files loaded from #INCLUDES and libraries.
I plan to bring these functions to the v1 script as well, but i need more time to test and work out bugs in the v2 script before i do that.
EDIT: As for command line parameters, I could develop that, but wouldn't it be easier to just use this script as an #INCLUDE and populate the Settings object directly? Then call ReParseText(). Wouldn't that be easier?
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
That is totally fine with me.
I personally would not create two scripts, though. The one script should just support AHK v1 and v2. Which exe the script needs is irrelevant IMHO.
I personally would not create two scripts, though. The one script should just support AHK v1 and v2. Which exe the script needs is irrelevant IMHO.
ciao
toralf
toralf
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
@toralf
I'm not sure how I can make one script support both AHK v1 and v2 without actually making 2 different scripts for the different versions. The syntax is very different.
How would you approach that solution?
I'm not sure how I can make one script support both AHK v1 and v2 without actually making 2 different scripts for the different versions. The syntax is very different.
How would you approach that solution?
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
I was under the impression that the syntax would not be that different. But I assume now that you have found the small pieces that make the difference.
In best case the main script is identical and only version specific code is handled by if statements (or sub branches of an associated object, e.g. in case of different regex statements or alike)
In best case the main script is identical and only version specific code is handled by if statements (or sub branches of an associated object, e.g. in case of different regex statements or alike)
ciao
toralf
toralf
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
Yah there are significant differences. LIke FileRead, outputVar, file.txt and outputVar := FileRead("file.txt"), and in regex AHK v1 will need "O)" option.toralf wrote: ↑03 Jun 2020, 01:56I was under the impression that the syntax would not be that different. But I assume now that you have found the small pieces that make the difference.
In best case the main script is identical and only version specific code is handled by if statements (or sub branches of an associated object, e.g. in case of different regex statements or alike)
The differences are actually not bad, and easy to pick up, but those differences in AHK v2 will break an AHK v1 script until it is modified for AHK v1.
EDIT: Oh, and GUI usage is COMPLETELY different (but better IMHO). Same usage flow, but very different syntax. I might make a script/class/library for easy conversion of AHK v2 to v1.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
Update 2020/06/03
- functionality / stability update for loading includes
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/02 - For AHK v2 (updated) / v1 (shelved)
@TheArkive, does the v2 script support calltips for both v1 and v2 scripts? But you want to make two scripts, one for v1 exe and one for v2 exe? And both are supposed to do the same thing? That seems like more work than needed. I'd recommend making one script which supports calltips for both versions but only runs on one of the executables, if the user doesn't have the relevant exe, it is easier for it to download it, than it is for you to maintain two versions of the same script. It is ofc much easier to write this script in v2
Cheers.
Cheers.
Re: CallTipsForAll v2 - 2020/06/03 - For AHK v2 (updated) / v1 (shelved)
@Helgef
Both the AHK v1 and v2 scripts are made to facilitate the usage of the "language files" i have created. I have made language files for AHK v1 and v2. So both versions of the script will display call tips for both AHK v1 and v2, but development on the AHK v1 version of the script is currently shelved until I can work out all the kinks and do more testing to make sure undesired behavior and errors can be found and fixed.
I have more work to do with the AHK v1 language files. The command syntax is a bit tricky since the order of parameters is actually flipped around compared to AHK v2 function syntax. This happens in many cases.
I guess you're right, I may be over-think this a bit ...
EDIT: I agree, writing this script in V2 is MUCH easier.
Both the AHK v1 and v2 scripts are made to facilitate the usage of the "language files" i have created. I have made language files for AHK v1 and v2. So both versions of the script will display call tips for both AHK v1 and v2, but development on the AHK v1 version of the script is currently shelved until I can work out all the kinks and do more testing to make sure undesired behavior and errors can be found and fixed.
I have more work to do with the AHK v1 language files. The command syntax is a bit tricky since the order of parameters is actually flipped around compared to AHK v2 function syntax. This happens in many cases.
I guess you're right, I may be over-think this a bit ...
EDIT: I agree, writing this script in V2 is MUCH easier.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/03 - For AHK v2 (updated) / v1 (shelved)
Ultimately I'm trying to make this script capable of displaying call tips, and processing classes / includes for more languages than just AHK. That's why much of the configuration of how to translate the text is included as regex in the language files. I'm reading up on the scintilla class made by @kczx3. I'm very interested to make my own text editor that embeds these call tips, as well as auto-complete, and any other features that I have come across.
Of course I'll gladly take requests (if I get that far) to make as many useful features as possible, but of course have them implemented in the most intuitive way possible as well.
Of course I'll gladly take requests (if I get that far) to make as many useful features as possible, but of course have them implemented in the most intuitive way possible as well.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/03 - For AHK v2 (updated) / v1 (shelved)
@TheArkive
It’s important to note that the class I wrote was really just tweaked to work on v2 from RaptorX’s and @Alguimists version for v1. And it was written for V2-a100 so a ton has changed.
It’s important to note that the class I wrote was really just tweaked to work on v2 from RaptorX’s and @Alguimists version for v1. And it was written for V2-a100 so a ton has changed.
Re: CallTipsForAll v2 - 2020/06/03 - For AHK v2 (updated) / v1 (shelved)
@kczx3
Yah i noticed that in the comments. Of course I don't expect everything to work 100% perfect. I planned on tweaking it, if necessary, and assuming I'm still able/willing to get to that point ... of course I'm overcoming other hurdles at the moment.
I thought your solution was very elegant and simple, and even if some things don't work I should be able to dig into the docs for scintilla and puzzle out the stuff that doesn't work to fix it for v2-a108/a109.
Yah i noticed that in the comments. Of course I don't expect everything to work 100% perfect. I planned on tweaking it, if necessary, and assuming I'm still able/willing to get to that point ... of course I'm overcoming other hurdles at the moment.
I thought your solution was very elegant and simple, and even if some things don't work I should be able to dig into the docs for scintilla and puzzle out the stuff that doesn't work to fix it for v2-a108/a109.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/03 - For AHK v2 (updated) / v1 (shelved)
Another question for the script watchers:
Usually when i create a class, i will split up the code for methods into multiple methods if the task big enough. These methods aren't "meant" to be used directly. And of course events that correspond to a method (func / bound func obj) aren't used directly either.
I'm going to add a simple modification to the regex that identifies methods to capture comments on the same line as a method, probably will match ; hide or similar to make an easy way to filter out methods from the call tips that are meant to be internal.
The properties that are actually defined in a class are the only ones that will show up in call tips.
====================================================
EDIT: Clarification: properties defined with: property[] => expression, and defined by property { ... }, both with or without [], will be listed, all other properties simply created by this.property := value or static property := value will not be listed. The goal is to assist with displaying a call tip that helps users learn to use the class, not to map out every internal structure of the class. It is also possible to extend ; hide to include these other styles of properties if that kind of functionality is desired. Making these kinds of properties show up could be done with a comment regex match like ; show.
====================================================
Does this behavior sound logical for a call tips script? Any other comments related to this are welcome!
Usually when i create a class, i will split up the code for methods into multiple methods if the task big enough. These methods aren't "meant" to be used directly. And of course events that correspond to a method (func / bound func obj) aren't used directly either.
I'm going to add a simple modification to the regex that identifies methods to capture comments on the same line as a method, probably will match ; hide or similar to make an easy way to filter out methods from the call tips that are meant to be internal.
The properties that are actually defined in a class are the only ones that will show up in call tips.
====================================================
EDIT: Clarification: properties defined with: property[] => expression, and defined by property { ... }, both with or without [], will be listed, all other properties simply created by this.property := value or static property := value will not be listed. The goal is to assist with displaying a call tip that helps users learn to use the class, not to map out every internal structure of the class. It is also possible to extend ; hide to include these other styles of properties if that kind of functionality is desired. Making these kinds of properties show up could be done with a comment regex match like ; show.
====================================================
Does this behavior sound logical for a call tips script? Any other comments related to this are welcome!
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/08 - For AHK v2 (updated) / v1 (shelved)
Update 2020/06/08
- improved classes parsing
- use ; hide comment to hide methods / properties of all types
- use ; show comment after first-line class brace { to hide all elements, and use ; show comment after each element to selectively show elements
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/08 - For AHK v2 (updated) / v1 (shelved)
@Helgef, @toralf, and anyone else keeping an eye on this script.
Currently, the last member of a nested element is the only part that is stored when identifying an object. That internal list only tracks object names and a list of possible object type matches (like LIstView + GuiControl, etc). As long as no two elements are named the same in an entire script, this should suffice for dealing with user objects, except for one thing:
Is this perhaps going too far for expected behavior? If so, then I can move on to auto-complete.
- class parsing, and parsing of methods and properties is done, and filtering elements not intended to be used is easy and unobtrusive
Currently, the last member of a nested element is the only part that is stored when identifying an object. That internal list only tracks object names and a list of possible object type matches (like LIstView + GuiControl, etc). As long as no two elements are named the same in an entire script, this should suffice for dealing with user objects, except for one thing:
- When user objects are created and properties attached, the data members (most are properties) aren't tracked yet, and of course keys for maps aren't tracked either.
Is this perhaps going too far for expected behavior? If so, then I can move on to auto-complete.
« AHK Portable Installer » | « CallTipsForAll » | « TheArkive AHK v1 Scripts » | « TheArkive AHK v2 Scrpts » | « TheArkive on GitHub »
Re: CallTipsForAll v2 - 2020/06/08 - For AHK v2 (updated) / v1 (shelved)
Of cause it would be great if user objects would become "explorable". But I assume auto-complete would currently have a larger benefit for the user. Just my 2 cents.
ciao
toralf
toralf
Return to “Scripts and Functions (v2)”
Who is online
Users browsing this forum: Spydor, TomDonovan and 35 guests