Added a tooltip for the item currently selected in the suggestion box.
Heh... not really what I had in mind xD.
If I use, for example c_messageAreaSubtitle, I get a tooltip like this: Field: const int c_messageAreaSubtitle
Yeah, thanks, I knew that :D.
I am interested in the value, in this case "5", but I cannot find it anywhere, at least not without searching the natives.
Fixed an issue where the suggestion list sometimes wouldn't show any suggestions.
This still does not seem to work properly. For example, whenever I am creating a new trigger using the Trigger keyword, I don't get any suggestions for the events or actions first.
The problem with that is that it is only giving out of method suggestions. The placements of the methods are only updated when the script can go through the parser (try to compile the script. If you get errors like expecting: ';', then it didn't go through the parser.).
And according to the parser, triggers must have an action body. For triggers, I can relax that, and check it at a later time, but in general, if you made a syntax error, and expand a method or define a new one, you might not get in method suggestions there.
So you need to add the action body, before being able to get suggestions for the events part? Feels a little counter-intuitive, since you might want to add the events to the trigger first, before finishing the body.
Alternatively, you could implement auto-completion for the triggers, for example when adding the { after writing Trigger t {, it could finish the event and action bodys straight away, so after opening the first bracket, you will have this automatically:
Triggert{events{}actions{}}
since you will probably never need triggers created this way without the events and actions. You could make this optional as well.
I don't know if this is an active project but I see the last post is 21 hours ago. I also don't know if this has already been done. Would it be possible to add generic functions?
Not sure if that would be helpful but I assume a simple static generic function would be good to have. I don't think it would be harder to code than what you have currently done.
I have been looking into this and similar stuff in the past, but I have problems making the parser accept a language with that syntax. With my current parser, it has to be able to uniquely determine what you are writing by only looking one or two tokens ahead. The problems with generics in expressions is that they conflict with the less than expression. If you write
boolfoo=bar<baz[...
It wouldn't know if it's a less than or the beginning of a generic function call.
The solution would be for me to change parser, and I might look into that, but that is a rather big thing to do, that will probably take a while.
I could, but I'm curious - how do you plan to do it? How much of the editor do you plan to integrate (only compiler, or also the editor with syntax highlight and auto completion)? How will you handle new versions of the editor I release?
Also - the code is really written for my eyes only. As a result, there might be an insufficient amount of green lines, and you might find it a bit messy at times.
Its okay, my code is not commented too. First i will make it, second i will make it work, and finally i will make it work better :D Firstly I'm planning to generate messages on important events (like save), which will be handled with Lua script. I'm working on it now. So your parser should be able to be called from outside as automatic command-line tool (with source and destination filenames as parameters). You should take a look on TESH source code, because I'm planning to integrate the editor too. This is the harder part and we probably will need a good cooperation.
The autocomplete list now hides after inserting when double clicked.
Fixed an issue where method calls from while conditions to inline methods would be translated incorrectly.
Fixed an issue where assignments to a variable used in a while conditions could be incorrectly optimized.
Fixed an issue where the code foo = new Str(foo); would be translated incorrectly.
The program now checks that you don't use invalid characters in file names.
The program now monitor the source files. If one is deleted on the hard drive, it is removed from the project. (It still doesn't monitor rename, create or move)
Added deconstructors (See documentation).
Fixed some other bugs.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Could you display the value of a constant when you use it?
@Kueken531: Go
That I can do.. v2.6.0
Heh... not really what I had in mind xD.
If I use, for example c_messageAreaSubtitle, I get a tooltip like this:
Field: const int c_messageAreaSubtitle
Yeah, thanks, I knew that :D.
I am interested in the value, in this case "5", but I cannot find it anywhere, at least not without searching the natives.
Ah.. right - well, I made it for user defined constants.. but I can add it for the library constants aswell
Ah, okay, didn't check user-defined ones. Thanks
€ perfect.
This still does not seem to work properly. For example, whenever I am creating a new trigger using the Trigger keyword, I don't get any suggestions for the events or actions first.
The problem with that is that it is only giving out of method suggestions. The placements of the methods are only updated when the script can go through the parser (try to compile the script. If you get errors like expecting: ';', then it didn't go through the parser.).
And according to the parser, triggers must have an action body. For triggers, I can relax that, and check it at a later time, but in general, if you made a syntax error, and expand a method or define a new one, you might not get in method suggestions there.
@SBeier: Go
So you need to add the action body, before being able to get suggestions for the events part? Feels a little counter-intuitive, since you might want to add the events to the trigger first, before finishing the body.
Alternatively, you could implement auto-completion for the triggers, for example when adding the { after writing Trigger t {, it could finish the event and action bodys straight away, so after opening the first bracket, you will have this automatically:
since you will probably never need triggers created this way without the events and actions. You could make this optional as well.
I don't know if this is an active project but I see the last post is 21 hours ago. I also don't know if this has already been done. Would it be possible to add generic functions?
Not sure if that would be helpful but I assume a simple static generic function would be good to have. I don't think it would be harder to code than what you have currently done.
I have been looking into this and similar stuff in the past, but I have problems making the parser accept a language with that syntax. With my current parser, it has to be able to uniquely determine what you are writing by only looking one or two tokens ahead. The problems with generics in expressions is that they conflict with the less than expression. If you write
It wouldn't know if it's a less than or the beginning of a generic function call.
The solution would be for me to change parser, and I might look into that, but that is a rather big thing to do, that will probably take a while.
Could you add an option to not run the debug window when testing?
Just made a small update.. v2.6.3
@Kueken531: Go
I could give you the option to define all the command line args sent to Starcraft II. Why don't you want it shown?
The trigger debug window slows down the game massively, which is quite obstructive for performance tests or prolonged testing periods.
Don't get me wrong, it is immensely useful in most cases, but sometimes, I'd like to start the game without it.
I would prefer a simple checkbox over the command line, though.
What do you think about a changelog within the program, or when updating to a new version?
I released a new version.. v 2.6.4
The change log will automatically update to the newest version, even if you haven't updated (if it has internet connection).
Is "costimize" a word? xD
Thanks for the fast update, once again.
Busted.. :( I don't spell check my change log.
Hi SBeier
Can you create a git repo for this project on github? I want to fork it and try to integrate with my Gemini project.
I could, but I'm curious - how do you plan to do it? How much of the editor do you plan to integrate (only compiler, or also the editor with syntax highlight and auto completion)? How will you handle new versions of the editor I release?
Also - the code is really written for my eyes only. As a result, there might be an insufficient amount of green lines, and you might find it a bit messy at times.
Its okay, my code is not commented too. First i will make it, second i will make it work, and finally i will make it work better :D Firstly I'm planning to generate messages on important events (like save), which will be handled with Lua script. I'm working on it now. So your parser should be able to be called from outside as automatic command-line tool (with source and destination filenames as parameters). You should take a look on TESH source code, because I'm planning to integrate the editor too. This is the harder part and we probably will need a good cooperation.
v 2.6.5 is out: