ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

DonationCoder.com Software > Finished Programs

DONE: On Screen Button That Sends Keyboard Commands

<< < (15/47) > >>

cranioscopical:
Let's see what you find-Ath
--- End quote ---

I find that I was expecting to create a panel from scratch using WBE and that I don't know how. This may mean that first I have to read something somewhere  :o

Rather than simply editing what's there (very easy to do with WBE) I wanted to start with a clean slate.
If I start with an empty .ini I can't use the button fields in WBE so, obviously, I've missed the point.

Looking through the winbuttons.ini, however, I did find one remarkably apposite variable, viz. dummy.

Ath:
So I've been trying out the editor (according to the about box, I see 0.8.1.0) a bit and have some initial feedback:
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Great, thanks for this extensive feedback :Thmbsup:

I found choosing a color via the "Change..." button for Color to not work if starting with a blank value (no value got filled in to the text field for Color:), while I found that the corresponding choosing sequence of actions for Textcolor did work.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
I can see no difference for these two buttons (not in code, nor when testing), but when 'creating' a custom color, it needs to be added to the colorset by using the button 'Add to Custom Colors' before it will stick. (This has been tested quite extensive before release. It uses the standard AutoIt Color Selection Dialog with any of it's 'peculiarities' that I can't do much about)

Any chance of Control+A selecting all text in text fields?
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Eh, it does what you expect on my system, and I have done nothing in WBE to enable or disable that. Got another script catching ^A, perhaps? (AKA: Works on my machine... :o)

I accidentally opened the WinButtonEdit.ini in the editor -- not a good idea right?  Any chance of some kind of warning or protection?
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
I'll add a check/warning in the next release.

I see that clicking on a button in the preview will select a node in the tree -- except it doesn't appear to work for the Pink-Online button in <no group> in my default WinButtons.ini.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Correct. That button in the preview is disabled (that should be visible...) by a Condition, so the OnClick doesn't fire. In the Options menu there's ''Assume all Conditions True (not saved)" just for that. The 'not saved' part tells that this setting isn't persistent between sessions of WBE.

In the tree view, multiple nodes appear selected sometimes: view WinButtons.ini, choose <no group>, ensure the corresponding treeview is expanded, choose scite, ensure the corresponding treeview is expanded, click on the 'Push 1ce' button in the preview, click on the Notepad node under the <no group> treeview
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Hm, another case of 'Works on my machine...' weird. I do the de-selection and selection of treenodes using standard AU3 included functions, and can not see what you describe. I'll test some more, and add a small delay in between, that might improve things.
Could be something with the OS/Video drivers, what's your configuration? (Tested with Win7 with Aero on nVidia GTS 250 with drivers 8.17.12.5896.)
Also tested on WinXP running on VMWare and on 125%/120 DPI, and I see some odd behavior there. I'll try to fix that, if possible. The treeview control is a nasty beast sometimes, I've seen in the past :(

When I open WinButtons.ini, initially I don't see a + expander next to the scite group in the left pane.  When I select the scite group though, the + expander appears.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
I've seen that and don't know how to solve it. The + expander appears when I move my mousepointer over it (on Win7). The current 'workaround' is to set option "Expand all button groups after load" 8)
On WinXP I can duplicate this issue, I'll try to fix this if possible, too.

When there isn't much space in the preview, is there a good way to move it without accidentally pushing the buttons that fill most of the space?
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Besides aiming very accurately 8), you could enable "Show Window Border" and "Display Windows Close button" in the "Global parameters" tab, so the default 'handles' appear, or increase the "Button margin" value a bit. For this reason I've positioned the preview by default on the right/top side of WBE (instead of the runtime position for WinButtons), so it isn't covering any part of WBE.

Regarding WinButtons itself, is there any support for dropping things on to buttons?  I searched for relevant information in this topic and WinButtons.Readme.txt unsuccessfully.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
WinButtons is not a drop-target, but I could add that if you want/need it. Could you give a more elaborate description for what/how you'd expect to happen there?

Thank you for:

Environment variables can be used by using %env.variable%

--- End quote ---
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
:) That's just the default Environment variables expansion available in AutoIt. It was a 'nice to have' feature and quite easy to add 8)

I didn't find it in the docs, but by looking at the samples I noticed that it looks like one can use relative paths.  :Thmbsup:
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Yep, I try to use a relative path after the executable file for WinSendKeys is picked using the file-browse dialog. It's not in the same subdirectory on my system, as the sample shows. The Run/RunWait AutoIt function is quite flexible in this.

I'll try to release an updated version this weekend.

ewemoa:
Thanks for the intents to attend to certain issues, the clarifications, and work-around suggestions :)

...and now to respond to a few points:

I found choosing a color via the "Change..." button for Color to not work if starting with a blank value (no value got filled in to the text field for Color:), while I found that the corresponding choosing sequence of actions for Textcolor did work.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
I can see no difference for these two buttons (not in code, nor when testing), but when 'creating' a custom color, it needs to be added to the colorset by using the button 'Add to Custom Colors' before it will stick. (This has been tested quite extensive before release. It uses the standard AutoIt Color Selection Dialog with any of it's 'peculiarities' that I can't do much about)
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
I think I chose a custom color for the first button but not the second.  My bad.

Any chance of Control+A selecting all text in text fields?
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Eh, it does what you expect on my system, and I have done nothing in WBE to enable or disable that. Got another script catching ^A, perhaps? (AKA: Works on my machine... :o)
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
No scripts running when I tested -- once via a VirtualBox Windows XP SP3 guest and once on a notebook running XP SP3.  I hear a sound but there is no selection.

In the tree view, multiple nodes appear selected sometimes: view WinButtons.ini, choose <no group>, ensure the corresponding treeview is expanded, choose scite, ensure the corresponding treeview is expanded, click on the 'Push 1ce' button in the preview, click on the Notepad node under the <no group> treeview
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Hm, another case of 'Works on my machine...' weird. I do the de-selection and selection of treenodes using standard AU3 included functions, and can not see what you describe. I'll test some more, and add a small delay in between, that might improve things.
Could be something with the OS/Video drivers, what's your configuration? (Tested with Win7 with Aero on nVidia GTS 250 with drivers 8.17.12.5896.)
Also tested on WinXP running on VMWare and on 125%/120 DPI, and I see some odd behavior there. I'll try to fix that, if possible. The treeview control is a nasty beast sometimes, I've seen in the past :(
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
Reproduced issue in the same environments as mentioned above (XP SP3).

Regarding WinButtons itself, is there any support for dropping things on to buttons?  I searched for relevant information in this topic and WinButtons.Readme.txt unsuccessfully.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
WinButtons is not a drop-target, but I could add that if you want/need it. Could you give a more elaborate description for what/how you'd expect to happen there?
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
I was thinking it might be nice if it were possible to specify in the configuration that a certain action would be taken upon drop (e.g. execute a command passing the path of what's dropped -- assuming what's dropped has a path or set of paths).  Does that make sense?

Ath:
Any chance of Control+A selecting all text in text fields?
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
Eh, it does what you expect on my system, and I have done nothing in WBE to enable or disable that. Got another script catching ^A, perhaps? (AKA: Works on my machine... :o)
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
No scripts running when I tested -- once via a VirtualBox Windows XP SP3 guest and once on a notebook running XP SP3.  I hear a sound but there is no selection.
-ewemoa (June 11, 2011, 07:35 AM)
--- End quote ---

Tested on XP and it just beeps at me, but no selection, then tried on a Win7 virtual (not my default Win7 system) and a Vista virtual, and from Vista and up Ctrl-A selects the content of the edit. Seems that's a feature since Vista was introduced :o


Regarding WinButtons itself, is there any support for dropping things on to buttons?  I searched for relevant information in this topic and WinButtons.Readme.txt unsuccessfully.
-ewemoa (June 10, 2011, 06:14 PM)
--- End quote ---
WinButtons is not a drop-target, but I could add that if you want/need it. Could you give a more elaborate description for what/how you'd expect to happen there?
-Ath (June 11, 2011, 06:27 AM)
--- End quote ---
I was thinking it might be nice if it were possible to specify in the configuration that a certain action would be taken upon drop (e.g. execute a command passing the path of what's dropped -- assuming what's dropped has a path or set of paths).  Does that make sense?

-ewemoa (June 11, 2011, 07:35 AM)
--- End quote ---
I'll see what I can come up with, sounds kinda intriguing 8) (never did much drag&drop-related stuff)

All other issues & promises: I'll do my best in fixing asap.

Ath:
I find that I was expecting to create a panel from scratch using WBE and that I don't know how. This may mean that first I have to read something somewhere  :o
-cranioscopical (June 10, 2011, 06:17 PM)
--- End quote ---
Thanks for trying WinButtonEdit, I was kinda expecting you to find something :)

IMHO WBE is too small a tool to warrant a wizard, but I'll see if I can improve the User experience here.

Rather than simply editing what's there (very easy to do with WBE) I wanted to start with a clean slate.
If I start with an empty .ini I can't use the button fields in WBE so, obviously, I've missed the point.

Looking through the winbuttons.ini, however, I did find one remarkably apposite variable, viz. dummy
-cranioscopical (June 10, 2011, 06:17 PM)
--- End quote ---
I thought I had that all covered during testing, but I wasn't thorough enough it seems. :-[
Expect this issue to be fixed in the next release

And the work-around for this issue is to save and re-open the new file (but it's not yet in the MRU)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version