Unreliable results changing GUI color on keypress. Topic is solved

Get help with using AutoHotkey and its commands and hotkeys
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Unreliable results changing GUI color on keypress.

07 Nov 2017, 00:31

As seen here:

Image

The three rectangles at the bottom are individual GUIs that the Edit boxes submit hex values to and those update color reliably, exactly what I want for storing certain temporary colors, and the ones near my cursor are for modifier visualization, so when I'm holding down control, shift, or alt. When I connect the variable color to the modifier keys, they tend to flash the original color every 3rd or so keypress (but it seems random) and I'm not sure how to fix this. This is what I'm going for:

Image

Right now I can't get more than one modifier key to light up at the same time, and I don't know how to address the image overlay above that. I figure that I would need to use GetKeyState to display a different image depending on which modifier keys are being held, but I don't really know how to approach building it from a conditional statement or where to put it/how to trigger it--which is why I used KeyWait to change colors in the working sample at the top. Parts of the script:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



Can I get a point in the right direction or a barebones pseudocode example of how to fix the above so I can have multiple keys light up? Its a roadblock for me because all I need to do to finish is the same conditional show/hide for the mouse charts above it. I'm a very visual person and I have a hard time extrapolating the logic when not in the direct context I'm trying to use it for--I haven't had to use anything but basic one line If statements, and I don't know if I would have to trigger it within the hotkeys and only for the ones they effect, or outside of it using something like SetTimer or Loop, or where to even put it in my code. I'm new to coding and have stumbled my way this far.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

07 Nov 2017, 09:55

Bump for visibility. I'm new to coding and could really use some help.
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.  Topic is solved

07 Nov 2017, 11:27

:arrow: You can use the following modifier symbols to define hotkeys:
The * symbol might help.
BTW: If all parts of the picture shown in the OP are parts of your own GUIs, why do you think to need different GUIs?
Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

07 Nov 2017, 13:19

just me wrote::arrow: You can use the following modifier symbols to define hotkeys:
The * symbol might help.


Image Well that makes me feel really dumb lol. I plugged that in and it works, I was actually using wildcard in other hotkeys but I'd read a post claiming this was an implicit limitation of KeyWait so that's where I thought the problem was--thanks though! It fixed the color too but admittedly I'm not sure why it would since I was only doing single keypresses in the gif above.

just me wrote:BTW: If all parts of the picture shown in the OP are parts of your own GUIs, why do you think to need different GUIs?


What would you recommend? I'm really new to coding and I have a hard time extrapolating things if not in the direct context I need them, I couldn't find examples of GUIs or controls changing color to Edit boxes like the above. I had compatibility problems trying to write them all in the same script too, I have 9 total hidden within the UI of Adobe Illustrator, and I found that it was much easier to debug them if I wrote new ones in a new script and ran that independently to make sure things work and to have a better idea of where the conflicts were.

Would you be able to point me in the right direction or help me get started on the conditional image overlay above the keys? I don't understand where I'd put that in a script, and the only way I can think to do it is to have a long single conditional expression using GetKeyState with all the explicit Down/Up states that each contain a rebuild of the intended GUI every time--so I fear I'm overcomplicating since that's the source of most of my AHK problems so far--I haven't had to do anything but really simple If/Else statements yet so it's intimidating to the point of being reluctant to try (I don't know how many hours I'd spin my wheels doing things wrong rather than get someone with experience to give me some barebones pseudocode or advice), I'd really appreciate it.
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

08 Nov 2017, 05:43

To help you, we need more detailed information about what you want to achieve. Your animations seem to show various changes of parts of the GUIs. You should show your actual code and give a a verbal description about what every part of your GUIs should contain and under which condition it should be shown, hidden or changed.

I have 9 total hidden within the UI of Adobe Illustrator
The problem with this is, that your animation won't show hidden GUIs and the related code. So nobody can get an idea what they are intended to do.
Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

09 Nov 2017, 02:29

just me wrote:To help you, we need more detailed information about what you want to achieve. Your animations seem to show various changes of parts of the GUIs. You should show your actual code and give a a verbal description about what every part of your GUIs should contain and under which condition it should be shown, hidden or changed.

The problem with this is, that your animation won't show hidden GUIs and the related code. So nobody can get an idea what they are intended to do.


Sorry about that. By "hidden" I mean that I'd like to disguise them as native Adobe Illustrator panels as best I can because it's distracting when they're sore thumbs, I have it working in a new script now except for recreating the color updates of the bottom Edit boxes for hex values and their color tags:



Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



This works much better thanks to an example I was given though I can't imagine I've done everything right, my only trouble at the moment is recreating the updating color labels next to the Edits. How would I link progress controls to update to the edit boxes submitted value in the same gui without rebuilding? The way I'd done it previously was in having 4 separate guis and respawning them, I commented out the irrelevant parts but am including for clarity:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



I realize I'm doing a lot wrong in the initial code above with the guis, but the color labels did work for me that way. Admittedly a lot of the functionality for this GUI is aesthetic, but it's to supplement a 1400 line script on mouse remapping and the charts/key visualizers are essential for it so I don't have to remember all 70 shortcuts. I'd like it to stylistically look like this:

Image

I can make graphics for anything but I don't know of good approaches. The functionality from top to bottom is the mouse charts then key visualizers, then a batch number I'd use to append to the title in a cloned save to ensure having backups, below would be a number for stroke and offset effects, then a number I'm hoping I can control Loops with to send the arrow keys a specific number of times for moving shapes and transformations, then finally the three hex value edits and their color labels. I'm having a hard time making an Edit box without a border, or placing a transparent image with a border above the edit boxes to give a graphical overlay without compromising being able to easily access the Edit box itself. It's obviously not essential but I've seen a lot of struggles trying to do this through searches without many clear (or rather, simple) solutions. Any advice or suggestions to make the code better when you have time?
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

09 Nov 2017, 04:05

Hi Off Topic,

just a first note:

AFAICS, your complete 'Sidebar' GUI consists of the following parts:
  1. A Pic control with changing content dependend on the state of LControl, LAlt, and LShift keys (MouseGUI).
  2. An area of three controls indicating the state of this keys (ModGUI).
  3. An area used for some settings (NumberGUI).
  4. An area to set colors (EditGUI).
As yet I don't see any reason to not combine all parts in one GUI.

1.Related to key states (not tested):
You don't have problems to create images. So if you don't need to reflect the current colors of the EditGUI to indicate the modifier states, you might use some nice Pic controls and GuiControl, Hide/Show to hide/show them accordingly to the key states, for example:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Remaining with AHK 1.1.25.02 until v2 will become beta.
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

09 Nov 2017, 05:47

2. Related to the color Edit controls (tested):

You can change the background color of the Edit controls by specifying the ControlColor option of the Gui, Color, ... command. But this will also affect some other control types. If this is unwanted, there are other options to set individual background and text colors for Edit controls.

If you want to remove the frame, you can specify -E0x200 in the Edit control's options, but you have to adjust the position of the control in this case.

To update the Progress controls by pressing Return within the Edit controls, you might want to use a context-sensitive hotkey:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

11 Nov 2017, 20:57

just me wrote:Hi Off Topic,

just a first note:

AFAICS, your complete 'Sidebar' GUI consists of the following parts:
  1. A Pic control with changing content dependend on the state of LControl, LAlt, and LShift keys (MouseGUI).
  2. An area of three controls indicating the state of this keys (ModGUI).
  3. An area used for some settings (NumberGUI).
  4. An area to set colors (EditGUI).
As yet I don't see any reason to not combine all parts in one GUI.




Real gui results so far:
Image

Sorry for the late reply, trying to opt for a good one rather than a timely one. I felt like there was a lot to learn in just those two snippets, and after a while of struggling to get both working simultaneously in my old script (user errors), decided to rebuild everything in a single gui like you've suggested (which is a much better way to do things). I appreciate the help, everything works in my new script with exception to being able to submit for the color strips to update during a hotkey. I've tried a few different approaches to no success; I can manually activate the edit then write a hex color and press enter manually for a successful color update, I can even target the gui with focus through a hotkey then hit enter manually to success, but nothing within a hotkey sequence while sending enter and I don't understand why. [Line 299 in "DropR"]

I also had a mysterious blue color appear when I tried to change your function to affect the foreground color of the progress rather than the background. I edited the function and the control to what I expect would work, and it did have it working--but I couldn't get the background to reappear and my progress control is strangely blue on startup which I don't understand. I wanted to use the background as the border or frame by keeping it a static grey (#2B2B2B) but I had to work around it by adding borders to the image underlay beneath.

I've taken care of everything else to try and learn more about AHK, but I'd still appreciate a look over what I'm doing if you have time. From lines 268-430, I'm copying data to then paste into the hex edits or vice versa into Illustrator panels, but the only way I know to do this is through my clipboard. I suspect there'd be a better way than GuiControlGet > Clipboard then Clipboard > AI Panel and it's not an interruption but it'd be nice to retain previous clipboard contents without clearing them in case they're shapes or objects within Illustrator. I'm including the full script below, also a link to Google Drive containing all the assets and a zip with everything bundled.

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



Lastly, without wearing out my welcome or hopefully appearing ungrateful, would it be impractical to simulate animation through changing GuiControl pictures every 40ms, 20ms, or 16.667 ms? I ask because I thought it'd be interesting to use loops containing GuiControls with png sequences that simulate 25 (or any I'd want) frames per second, so animations within loops that I could potentially break conditionally or have be interactive in some manner. I've seen that gifs are supported in gui displays but I don't see many discussions about using them interactively, and I'd specifically want to cushion animations like button presses with 3 to 5 frames to "ease in" or "ease out" of extreme poses when activated. If I could get away with it, I'd actually love to have multiple looping animations (which would be vector so very low data size and strict color profile, like my avatar or these icons in the gui) running on the gui but I'm not sure if it's pie in the sky or too cpu-intensive. Are there any examples that you've seen or know of, or any ways you think this would be best done? Avoiding flashing too?
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

12 Nov 2017, 05:59

Hi Off Topic,

no reason to apologize. I see you did much work in the meantime. I'll look at your script, but this might need some time. I cannot test here, because I don't have Illustrator and my display is much smaller than yours.

Some first questions:
1. Is the "Active Window Info (Window Spy" (contained in the AutoHotkey entry in the Start Menu) able to get Information about the Illustrator controls you want to change?
2. What are the WinActivate, ahk_class tooltips_class32 Hwnd0x2b0436 commands intended to do? Is it actually the correct class name?

If you want to update the related Progress control after you changed a color Edit using a hotkey, you don't need to send Enter/Return to the Edit. You know which Edit has been changed, so just update the correspondend Progress with the new value directly. Also, you should use the name of the associated variable instead of the ClassNN to access the controls.

To keep the current contents of the clipboard, store it before you empty the clipboard and restore it after you have done what you want:

Code: [Select all] [Download] GeSHi © Codebox Plus

SavedClipboard:= ClipboardAll
Clipboard := ""
...
...
Clipboard := SavedClipboard
Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

12 Nov 2017, 17:13

Thanks for the tips, changing the progress control seems obvious in retrospect, lol. That's also a very handy and simple way to retain the clipboard data, it's exactly what I'd needed.

1. Yes it is -- admittedly I was using a script that Leefme posted and I'd found in a search that displays HWND's in a tooltip to get the data. That was one of the first things I did with AHK and I was stabbing in the dark without knowing what to look for, but I now see that the specific Color edit box is listed as having the same exe (illustrator.exe) and class (illustrator) as my Illustrator edit window, explicitly says ClassNN Edit14.

2. I'm not sure if it's the correct class name after using Window Spy, which states the ClassNN as Edit14 instead. I'm trying to transfer the hexadecimal text from one of my gui's 3 hex edits to this Edit14 panel and vice versa in a way that wouldn't be an interruption to (or is too fast to interrupt me during) drawing in the edit window. I'm not sure if it had any effect since I was forcing a click after that WinActivate, but I didn't have errors so I kept it. I'm doing this in an admittedly crude way right now because I'm just sending my mouse there, clicking the edit box, copying/pasting the data then finishing by sending my mouse back to where it would likely have been before triggering the hotkey. I have the tab open and the edit box fixed in place so it's primitive and very simple, but it worked for me in the first iteration of my gui so I hadn't thought of updating to a better method. The panel on the rightside of my screen looks like this:

Image



In this speed drawing of a cube, I use the hex boxes at 0:30. Having this gui and using AHK is amazing for drawing with a mouse, it makes a world of difference in Illustrator.

No rush for replies. If I can make it easier for you in any way, feel free to say so.
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

13 Nov 2017, 03:38

O.K., please try the following to transfer from and to the RstripColor Edit (untested):

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus

Does it work for you?
Remaining with AHK 1.1.25.02 until v2 will become beta.
User avatar
Off Topic
Posts: 13
Joined: 07 Oct 2017, 20:57

Re: Unreliable results changing GUI color on keypress.

13 Nov 2017, 13:58

Wow, that's an incredibly direct way to do it. Thanks! I'll use that method for quite a bit going forward, I must've overlooked that in searching. The first one did send the control the text but Illustrator thought I was trying to move an object rather than submit when it simulated enter, but I've gotten it working by setting the Focus to the control just before and sending a regular enter stroke because the ControlSend didn't seem to work for me. So I now have:

Code: [Select all] [Expand] [Download] GeSHi © Codebox Plus



Makes a huge difference! It's really stunning how well that works -- I even tried it when the panels are minimized and it still reliably sends. Can't thank you enough, that will actually take care of me because I'm about to dive in real deep with using these examples in other contexts. So thanks for your time, my script is flawless at the moment, it's way better than I'd expected to make when I first started and using it in conjuction with Illustrator has really helped me in the learning curve. Feel free to knock if you're in need of vectors, icons, graphics, or animation, etc, and I'll happily oblige. I only have one or two more problems but I'm pretty sure I can solve them myself using these snippets and referencing the guide. Really appreciate all the help and expertise though, goes a long way in helping to encourage use (even though most answers are right in front of you in the Help Guide if you know where to look, there's so much text that it can be kind of overwhelming especially if not one who performs too well in that very literary style of learning).
just me
Posts: 4865
Joined: 02 Oct 2013, 08:51
Location: Germany

Re: Unreliable results changing GUI color on keypress.

14 Nov 2017, 02:50

I'm pleased I could help you. If you need further help, post your current version of the script or the problematic parts. I'll have a look, then.
Remaining with AHK 1.1.25.02 until v2 will become beta.

Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], Yahoo [Bot] and 48 guests