I'm using AutoIt to try and make a little hotkey application to work with Windows Journal so I can quickly select different colors.
It seems I'm very close and yet very far to getting the desired result. I've used the AutoIt tool to find the CommandID of the toolbar and the ID of the colors. Here is my code:
ControlCommand("[CLASS:JournalApp]","",113,"SendCommandID", 40178)
My problem is that the color will not be selected. It will be selected to the degree that the color will have the "selection" brackets around it, but the color that I draw with will still be the last color I've selected.
So I tried messing around and found that this code:
ControlCommand("[CLASS:JournalApp]","",113,"Check","")
It will indeed select the color, but it will only select the light blue color. I don't know why, but that is the color that is always being selected. I have not found a way to combine the selecting ability of "SendCommandID" with the checking ability of "Check"
Also, it is a ToolbarWin32 Control.
I figured it out myself.
Here's what I've learned:
ControlCommand("[CLASS:JournalApp]","",113,"Check","")
Has a serious weakness in that it there is no way to specify which button will be checked. At first it seemed to be random, but after a while of playing around I noticed that it did it at a specific coordinate relative to the client window. Why? I have no idea. But at least it's not random.
ControlCommand("[CLASS:JournalApp]","",113,"SendCommandID", 40178)
Has a weakness in that, while on the surface it appears to have successfully clicked the button. The button's function is not actually executed. For my specific circumstance, the color of the pen did not change after I used this, though it appeared to click on the button.
Here's my solution(s):
I looked around and found that AutoIt has a library specifically for dealing with ToolBarWin32 Classes. This is the library from GuiToolbar.au3. With this I found that I was able to do a few things. One, was that I could send clicks to the buttons and change the state of the buttons even. I found that changing the state of the buttons did nothing in relation to triggering an event and the clicking worked, but it had the weakness that it caused the mouse to flinch. This did not work because my pen was near my tablet as that has priority of mouse movement. So I had to raise my pen away from my tablet in order to use the hotkeys--not very convenient. Here was my code for that solution:
if WinActive("[CLASS:JournalApp]") Then
WinActivate("[CLASS:ToolbarWindow32; INSTANCE:2]", "")
$cmdId = "401"&$hotKeys[$key-1+$shift]
If $cmdId < 40172 or $cmdId > 40188 Then
Return
EndIf
$hWnd = ControlGetHandle("[CLASS:JournalApp]", "", 113)
_GUICtrlToolbar_ClickButton($hWnd, $cmdId)
EndIf
What I found after was that AutoIt's native ControlClick() was a lot more useful in that it didn't cause the mouse to flinch whatsoever. It triggered the mouseclick event directly. So that in combination with a nice command from the toolbar library made for a much cleaner solution. Here it is:
if WinActive("[CLASS:JournalApp]") Then
WinActivate("[CLASS:ToolbarWindow32; INSTANCE:2]", "")
$cmdId = "401"&$hotKeys[$key-1+$shift]
If $cmdId < 40172 or $cmdId > 40188 Then
Return
EndIf
ConsoleWrite($hotKeys[$key-1])
$hWnd = ControlGetHandle("[CLASS:JournalApp]", "", 113)
;get the coords of the button and control send a click
local $btnCoords= _GUICtrlToolbar_GetButtonRect($hWnd, $cmdId)
ControlClick("[CLASS:JournalApp]", "", "[CLASS:ToolbarWindow32; INSTANCE:2]","left",1,$btnCoords[0]+2,$btnCoords[1]+2)
EndIf
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I'm trying to create a program that creates three buttons on the right side of the screen.
When I press a button, the entire background will change color (each button will make the background a different color). Whenever the mouse is not pressed, the background will return to white. I'm having trouble understanding how to make the three rectangles into buttons.
THIS MUST BE DONE WITHOUT A SPECIAL BUTTON METHOD/LIBRARY
You need to break your problem down into smaller pieces.
Can you create a program that just shows a single button? Don't even worry about making it interactive yet. Just show a single button at hard-coded coordinates.
Now can you detect when the user clicks in that button? Just print something to the console. Get that working perfectly before moving on.
Now can you get multiple buttons working together? Again, just print somethign to the console, and make sure it works perfectly before moving on.
Finally, can you make it so pressing each button changes the background instead of printing something to the console?
If you get stuck on a specific step, you can post a MCVE along with a specific technical question. Stack Overflow really isn't designed for general "how do I do this" type questions. It's for specific "I tried X, expected Y, but got Z instead" type questions. So please try something and post an MCVE of a specific step you're stuck on. Good luck.
Check processing's documentation for mouseClicked() and mousePressed.
The former being a method called upon a click, and the later is a boolean that is constantly updated. (So you'd check for it in your draw())
You'd then want to check the mouseX and mouseY values to see if they are in your desired button's area. (Which would be displayed on screen using rect())
I need to display a tooltip over a window. I'm creating a second window with the tool tip and using SDL_RaiseWindow() to bring it to the top. However, doing that causes the tooltip to steal focus which is not what I want. Is there a way to bring a window to the top without changing focus?
Also, is there a way to set focus (mouse and/or keyboard) without changing the Z order of the windows?
The answer offered by Neil will only work under X11 as SDL_SetWindowInputFocus() is only implemented for that environment. In essence, the desired behaviour is otherwise not achievable. I have seen that there is a feature request in the SDL forums for an overload of the SDL_RaiseWindow() function to include an optional bool parameter to indicate if the raised window should also receive the input focus, or not. I hope they do implement that.
In any case, the support for multiple windows under SDL 2.x is a little weak. There is no built in support for the Z-order of different windows, and trying to build one based on the "painter's method" works, but leaves one no control over the input focus.
Old question, but this came up during my own search. You could try SDL_RaiseWindow() to bring your tooltip to the top, then use SDL_SetWindowInputFocus() on the main window to switch focus back to it.
I got this working sufficiently for my tooltips on mac by using SDL_WINDOW_ALWAYS_ON_TOP flag with SDL2:
SDL_CreateWindow(tooltip_window->name, x, y, w, h,
SDL_WINDOW_OPENGL | SDL_WINDOW_BORDERLESS |
SDL_WINDOW_ALWAYS_ON_TOP);
SDL_RaiseWindow(windowThatShouldHaveFocus);
// ...render what you want on that tooltip (SDL_RenderClear, SDL_RenderCopy, SDL_RenderPresent) & hide it with SDL_HideWindow
And when showing the tooltip:
SDL_ShowWindow(tooltipWindow);
SDL_RaiseWindow(windowThatShouldHaveFocus);
Just trying to get my head around Adobe Edge. What I want to achieve sounds simple but having real trouble. I have a button element, that when mouseover, displays an animated symbol I have.
Currently my code,on the button is Mouseout:
sym.$("pgicatext2").hide();
and mouseover:
sym.$("pgicatext2").show();
This doesn't seem to be working. I can achieve the result if, I turn off the movie symbol, and use this code on the button
sym.$("pgicatext2").toggle();
The trouble is of course it doesn't replay the animation every time you mouse over, and all the while it's hidden it's playing the animation.
I see its been a month since you posted this. Hopefully you solved your issue. Your code for hiding and showing looks right. One thing I have had happen in some of my projects is that I inadvertently placed an object or symbol with 0% opacity on top of a button or something I had a mouse over event. Make sure that the button you have does not have anything layered on top of it. Another thing would be to turn off autoplay of your symbol, and add sym.$("pgicatext2").play(); into your mouse over. I know those are pretty obvious answers, but sometimes it is easy to forget the obvious.
Please get through following steps:
Check if the button is over all other visible layers ('Elements'
tab). Maybe setting cursor to 'pointer' will help to check it.
Use 'Mouseenter' and 'Mouseleave' instead of 'Mouseover' and
'Mouseout'. The difference is explained here.
Make sure that your animated symbols 'autoplay' option is off. If
you did not tick it off while creating the symbol, just set Playback
to 'Stop' on Stage at the very beginning of the timeline
Lets do some coding. Lets assume that your animated symbols name is
"film". You need to set following actions to your button element:
Mouseenter:
sym.$("film").show();
sym.getSymbol("film").play();
this basically shows up your 'film' element and plays 'film' symbol
Mouseleave:
sym.$("film").hide();
sym.getSymbol("film").stop(0);
this one hides your 'film' element and stops 'film' symbol at the beginning of animation (0ms)
Enjoy!
I'm trying to write a kiosk GUI in ruby/gtk on ubuntu. I'm pretty fluent in ruby, but new to writing GUIs and not great with linux.
I'm using a touch screen, and am using our own images for buttons, e.g.
button_image = Gtk::Image.new(Gdk::Pixbuff.new "images/button_image.png")
#button = Gtk::Button.new
#button.add(button_image)
#button.set_relief(Gtk::RELIEF_NONE)
My issue is that when the buttons are pressed or remain selected (or hovered over, although this is less relevant with a touch screen), gtk shows fat, square borders around them. Obviously it's applying gtk's prelight / selected / active lighting to the buttons. I've tried changing the button properties in various ways, and also tryied hacking apart my theme, and while I can modify how the highlighting looks, I can't seem to completely get rid of it. Changing the color of the highlight via my theme is easy, but if I remove my setting there's still a default I can't get rid of.
Does anyone know if there's a way to stop it, or possibly make it transparent? Thanks in advance!
Sounds like you want to use exactly your image for the whole button, instead of putting an image inside the normal GtkButton - but still use all the normal behavior of the button.
The easiest way to do this is to just override the drawing. If you are on gtk2, connect to the "expose-event" signal, do your drawing there, and return true so that the default handler doesn't get run. If you are on gtk3, connect to the "draw" signal and do the same.
I tried meddling with the drawing as Federico suggested, but found that the most direct way to address this was instead to use an event box rather than a button. Event boxes accept clicks just like buttons, but don't respond to selecting, hovering, etc. In ruby, the code looks like this:
image = Gtk::Image.new("myfile.png")
event_box = Gtk::EventBox.new.add(image)
event_box.visible_window = false
event_box.signal_connect("button_press_event") do
puts "Clicked."
end
Most of this is exactly like a button; the *visible_window* method, obviously, keeps the event box from being visible under the button image.