joedf wrote:Haven't had the time to check but are SciTE4AHK themes compatible with this? Since, they both use SciTE, no? maybe the lexer is somewhat different from yours?

The lexer of SciTE4AHK was probably written by PhiLho, whereas the one from AutoGUI was created by RaptorX. AutoGUI uses Scintilla, not SciTE. SciTE is a text editor by the same author of Scintilla (Neil Hodgson).

kczx3 wrote:Alguimist, I vaguely recall you mentioning that you want to rewrite the lexer used in this project.

There are basically two minor bugs in the Scintilla lexer of RaptorX: 1. When using colon in the beggining of a line, which may occur in the case of a long or concatenated ternary. 2. Code folding is not working properly with some files, like Gdip_All.ahk.

kczx3 wrote:Do you also have plans to add a lexer for AHK v2 syntax? It doesn't differ too much but you could basically ignore command syntax.

I'm not into AHKv2 yet, so I don't know where exactly it may be affected by the current lexer, apart from the absence of commands, which means that they are probably compatible, as you said. Perhaps all that has to be done is to append the list of commands to the list of functions when setting the keywords.

Hello - i'm little confused.
When I'm starting new gui in WYSIWYG, placing buttons etc. code is autocompleting to changes made on form.
Now when i click to editor - form disappear.
When i change some size and position and click "show hide preview window" - it looks like before and if I even move this preview form - all code i write undo ....
Why this preview doesn't stay visible and why it's not refreshing to display code changes?
Also Snapping to grid only snap control position not size - i cant have "snap-sized" buttons.

@BriHecato: see the comment of StefOnSteroids above, which is essentially the FAQ of AutoGUI.

In regard to the resizing of controls, it can be accomplished in three ways: 1. by dragging the small rectangles around the control; 2. holding Shift while dragging the control (this way the snap to grid also applies to the size); and 3. with Shift + arrow keys for 1 pixel adjustment or Ctrl + Shift + arrow keys for a higher increment.

Thanks, Alguimist,
guess I should have been more precize with my resizing problem of checkboxes. The resizing of the caption and overall control area works nice and also snaps into place with the grid if desired. But the checkbox itself remains the same size as before. No matter how large the caption, the actual area where the clicking takes place - for the tickmark off or on - always has the same size. Possibly a Windows limit - I am on Win7 - or I am probably overlooking something.

Is there a way to make the checkbox itself larger? I am asking in general ahk-terms, not specifically how to do it within AutoGUI. Any method, programatically or by mouse dragging at design time, would be welcome.

StefOnSteroids wrote:Is there a way to make the checkbox itself larger? I am asking in general ahk-terms, not specifically how to do it within AutoGUI. Any method, programatically or by mouse dragging at design time, would be welcome.

One way to make the checkbox icon larger is by means of custom icons for checked and unchecked states in a separate text control. Another way is to draw the checkbox with some Windows API functions. Example:

You forgot to release the device context inside the function.
While DrawFrameControl() may integrate well in a standard Win9x environment with its classic look, in a themed system it will stand out, and not in a positive way. First solution may be better.
There is a third solution: usage of a Wingdings font:

Wow, very impressive, and exactly what I had hoped for. You guys are awesome.
I am still in the process of figuring out how you did it, what parameters I need to tweak to change the box-size of the drawing version (approach No 2) - although not necessary, the current size is perfect.

Best of all, it's all set to go. The variables contain the correct state of the checkboxes - checked or unchecked - which still baffles me a bit, but that's another story, having to do with the different variable names referring to the same variable nevertheless (vChk1 vs Chk1, hChk1 vs hWndhChk1)

I also like the Wingdings solution a lot (approach No 3)
1) Is it safe to asssume that Wingdings will be present on all Windows machines?
2) Should I keep switching between Wingdings and Segoe (checkbox-symbol and Label) when setting up the GUI - or is it better in terms of speed and performance when I first let it draw all Labels, THEN switch to Wingdings and add all the checkboxes from that code line downwards? I have about 20 checkboxes on that form.

Regarding solution 3:
1. The Wingdings font is present from Windows 95 to at least Windows 7; I don't have newer Windows versions to check but hopefully someone here will fill in that missing information.
2. Fastest way remains your choice; depending on the capabilities of the destination machine(s) there may be no significant difference.

The Help manual will explain how variables and handles are declared in a Gui, Add command; that will eliminate the confusion you're having.
Please note that Alguimist's solution doesn't appear to redraw the checkbox controls in all situations, so you may end up with blank spaces in your GUI until clicking them (which would change their states). It also doesn't change states on clicking the text labels (that can be fixed following the logic in solution 3).

I've deleted my CloudMe account because of GDPR - the now legal base for privacy invasion and data theft.

Thanks again, Drugwash,
I'll go with the Wingdings solution, the font offers nice symbols to create different-looking checkmarks.
Yes, I noticed your implementation of clicking the text labels themselves, which comes in handy, too, because my form has some lengthy labels/ captions - makes it easy for the user to click onto applicable words while reading them, instead of having to aim for the checkbox-area. Yet another benefit in terms of usability.

My apologies for cluttering this subforum with something not directly related to AutoGUI or Editors per se. Maybe someone can move it to a more appropriate subforum where users are more likely to find it, should they have similar problems. I bet there must be others out there who find the built-in checkboxes way too small for today's high resolution displays.

The IDE marks all lines below the comparison as Strings. I believe that is because a opening "{" is expected.
I know the manual says the syntax is var := () = 1 ? "" : "" but here I don't need something to return to
a variable, I just need to "do something else" when two variables have some value or set them when they don't.
If my syntax is valid code, and it seems it is because it never failed me, than can this please be fixed?

I'm checking the Scintilla AHK lexer written by RaptorX, but I couldn't yet determine what is wrong. The lexer behaves as if an expression starting with an opening parenthesis in the beginning of the line is an option of a continuation section, like LTrim. Then, when a new line is entered, and while a closing parenthesis is not typed, it behaves as if the rest of the code is the content of a continuation section.

What you can do to avoid this syntax coloring issue, as a workaround, is to evaluate the expression to a variable so that the variable can be used as the condition without the need for parentheses. Or you can simply use a regular if-else block.

Alguimist wrote:@BriHecato: see the comment of StefOnSteroids above, which is essentially the FAQ of AutoGUI.

In regard to the resizing of controls, it can be accomplished in three ways: 1. by dragging the small rectangles around the control; 2. holding Shift while dragging the control (this way the snap to grid also applies to the size); and 3. with Shift + arrow keys for 1 pixel adjustment or Ctrl + Shift + arrow keys for a higher increment.

I've learned something, thanks.
Hope you improve further your tool in near future.