topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Thursday March 28, 2024, 8:27 am
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Last post Author Topic: DONE: On Screen Button That Sends Keyboard Commands  (Read 167466 times)

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #50 on: April 13, 2011, 10:33 AM »
Any chance this is related to a video driver, perhaps?

Yes, as I said, I suspect this is the problem.
Before trying anything else, I'm rolling the driver back (and forward as there's on later release than the one I have installed).

Usually (sub-)instances of WinButtons can be closed by pressing <Esc>

That was what I tried first. I have a lot installed on this machine, with plenty of potential for conflicts  :(

As you say, let's see what the test version does, but after I change the video driver again.

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #51 on: April 13, 2011, 01:43 PM »
(add althide=1 to the [Settings] section of WinButtons.ini) and -ah/-ah- command-line parameters to use an alternative Window Hide method
-Ath

-ah helps in that all of the buttons redraw on top (no more mystical gestures required) but the background remains transparent.
I had one instance of the copy menu that was transparent, but only one — can it be some sort of timing issue?

If I jump to the copy menu and then close it, and do that repeatedly, I'll get two instances of WB (two task-bar entries) that need to be terminated forcibly.

This is with earlier and later versions of the video driver for my machine.

I should try WB on a different machine (they're all XP SP3 here) which I'll try a little later today.

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #52 on: April 14, 2011, 03:56 PM »
After adding a possible compatibility fix, adding Tooltips to all buttons and some minor fixes, WinButtons 2.6.2.1 is released!

Download and read more at the release thread

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #53 on: April 14, 2011, 04:48 PM »
I still get this, probably my video card/driver.

WB2621.jpg

If I move the window (white and black in the attached image) over which part of WB is visible, those buttons move with it, while the area outside the window remains in place.
Clearly this doesn't happen with other users, so don't feel compelled to pursue it.

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #54 on: April 14, 2011, 04:56 PM »
You did try the althide=1 option I presume? If yes, then it's 99.9% chance of a videocard driver issue, IMHO.

Oh, and Always on Top is enabled by default, maybe it helps to turn that off (ontop=0)

Btw, I'm also interested to hear what video card you have in your system (don't recall if you mentioned that before) (maybe I should avoid that brand/model ;D)

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #55 on: April 14, 2011, 08:55 PM »
1) You did try the althide=1 option I presume? If yes, then it's 99.9% chance of a videocard driver issue, IMHO.

2) Oh, and Always on Top is enabled by default, maybe it helps to turn that off (ontop=0)

3) Btw, I'm also interested to hear what video card you have in your system (don't recall if you mentioned that before) (maybe I should avoid that brand/model ;D)

1) Yes
2) it doesn't
3) nVidia GeoForce 9600 GT 512Mb DDR3 — I'll happily admit it's the card but this phenomenon doesn't occur with any other piece of software, so that puzzles me a bit.

Here's a thing… I just tried it on another machine, entirely different video. Still XP SP3. Same phenomena.  :o

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #56 on: April 15, 2011, 04:09 AM »
Ok, I finally got a hold of some testing environments (XP, Server 2003, Win7 on 125%, all on VMWare) and lo and behold: I can reproduce the same 'bleed through' issues you have! :'(

So I re-researched the transparency style-settings of the window, and expect to have it fixed (works OK for me now on all my available environments).

The test-version of WinButtons 2.6.2.2-pre is attached to this message, later today (when I return home) I'll upload to the dcmembers server, and update the release-message.

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #57 on: April 15, 2011, 11:08 AM »
Ok, I finally got a hold of some testing environments (XP, Server 2003, Win7 on 125%, all on VMWare) and lo and behold: I can reproduce the same 'bleed through' issues you have! :'(

So I re-researched the transparency style-settings of the window, and expect to have it fixed (works OK for me now on all my available environments).


Bingo! Well done! Thanks for the perseverance.  Not just off to the races but first past the post.  :Thmbsup:


Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #58 on: April 15, 2011, 01:21 PM »
Bingo!
-cranioscopical (April 15, 2011, 11:08 AM)

Pfew! :beerchug: Glad we got that sorted. On both my daily-use Win7 x64 boxes it all ran fine, so I was caught a bit by surprise. I'll release formally in a bit, and I have a hopefully useful improvement in the works after that... (but that'll probably take until next week)

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #59 on: April 15, 2011, 02:04 PM »
With the kind help of cranioscopical I finally found what was giving the transparency issues with WinButtons. After a test-release earlier today, I can now present the official WinButtons 2.6.2.3 release.

Get the updated download from the original release-post

Post any bugreports, feature requests, questions (or praise :)) in this thread

Sneak peek for the next version...: Conditional display for all buttons 8) and after that I'll eventually have to start the WB-Editor-GUI :-[

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #60 on: April 15, 2011, 06:16 PM »
the WB-Editor-GUI


One is agog!

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
I've taken some time (and a work project that could nicely use it :tellme:) and added the condition<n> feature per button, and a few other goodies like multiple commands and a longer tooltip. So:

A new release is available: WinButtons 3.0

Get the download and all info from the original release thread

Requests, complaints, errormessages and other question can be posted in this thread. It's all welcome!

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
I've taken some time (and a work project that could nicely use it :tellme:)

Why work for money when you can work for nothing?  :D

Looking forward to delving into 3.0  :up:

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
I've taken quite some time and created WinButtonEdit, a GUI configuration editor for WinButtons configuration files.
Also added a few less major WinButtons features, like standard button surface- and text-color settings, and Group context switching based on the currently focused control. So:

A new release is available: WinButtons 3.1.2

Get the download (including WinButtonEdit) and all info from the original release thread

Requests, complaints, errormessages and other question can be posted in this thread. It's all welcome!

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
After testing for a few more days, I made a few improvements to WinButtonEdit RC1:
  • Improved handling of non-96 DPI screen settings, scaling and layout issues resolved
  • Dismissed systemtray icon
  • Improved handling of 'Reload last used WinButtons file' option

It is now WinButtonEdit 0.8.1 (RC2), and included with the download of WinButtons.

There have been no comments or bugreports, so I'm afraid not many people have tested it yet (I won't believe it's error-free ;D), so if there are any remarks, feature requests, bugs found, or a desperate need for the sourcecode (that's still not included), please don't hesitate to ask/report all of that here :up:

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #65 on: June 09, 2011, 09:49 PM »
@Ath

I was just looking at the first version earlier today. It's been on my to-do list for ages but I keep getting sidetracked into doing nothing (the sun's out).
Tomorrow I'll have a go: if anyone can break it, it'll be me  ;D  or, perhaps,  :-[  would be more appropriate.

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #66 on: June 10, 2011, 01:19 AM »
Chris,

Thanks you for your (planned) effort! It's a busy world, these days :tellme:
Let's see what you find ;D
« Last Edit: June 10, 2011, 01:21 AM by Ath »

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #67 on: June 10, 2011, 02:26 AM »
Re: WinButtonEdit

Wow, nice  :Thmbsup:  Was this a lot of work?

I think examining some of the bundled ini files using the editor will help me to experiment and learn how to use WinButton better.  Seems like it should lower the barrier-to-entry.

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #68 on: June 10, 2011, 05:03 AM »
Was this a lot of work?
Ehm, yes the changelog starts on may 3rd :-[ and I worked on it for 1 to 'a few' hours, 3 or four days a week, but the hardest part was taking generated source from Koda (the AutoIt GUI designer) to Scite without all generated errors and unneeded crap :-\. And then you move some controls a few pixels... :o
But I had fun (and inspiration) while working on it, that's the most important gain I had from it :up:

should lower the barrier-to-entry

That was the major goal

ewemoa

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #69 on: June 10, 2011, 06:14 PM »
But I had fun (and inspiration) while working on it, that's the most important gain I had from it :up:
+1

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:

  • 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.
  • Any chance of Control+A selecting all text in text fields?
  • I accidentally opened the WinButtonEdit.ini in the editor -- not a good idea right?  Any chance of some kind of warning or protection?
  • 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.
  • 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
  • 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.
  • 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?

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.

Thank you for:

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

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:

cranioscopical

  • Friend of the Site
  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 4,776
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #70 on: June 10, 2011, 06:17 PM »
Let's see what you find
-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

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.
« Last Edit: June 10, 2011, 06:20 PM by cranioscopical, Reason: Post first edit later »

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #71 on: June 11, 2011, 06:27 AM »
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:
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.
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?
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?
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.
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
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.
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?
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.
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%
:) 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:
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

  • Honorary Member
  • Joined in 2008
  • **
  • Posts: 2,922
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #72 on: June 11, 2011, 07:35 AM »
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.
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)
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?
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)
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
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 :(
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.
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?
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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #73 on: June 11, 2011, 08:19 AM »
Any chance of Control+A selecting all text in text fields?
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)
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.

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.
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?
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?

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

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,612
    • View Profile
    • Donate to Member
Re: DONE: On Screen Button That Sends Keyboard Commands
« Reply #74 on: June 11, 2011, 08:24 AM »
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)
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)
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)
« Last Edit: June 11, 2011, 08:38 AM by Ath, Reason: Added work-around »