In my WPF Application I have a menu. One of the option from that menu has a shortcut assigned: CTRL+B. In my application I also need a possibility to scan a bar code using bar code scanner.
My bar code is configured in a way where CTRL+B combination is used to specify the bar code starting point. In other words: Bar code scanner sends CTRL+B combination to tell me: "Hey I now starting to send you the bar code numbers".
I listening for the bar code input on Window_PreviewKeyDown event handler. This however does not work because firstly, application recognizes that CTRL+B was pressed and wants to call the command's executed method associated with the shortcut CTRL+B. Is there a way to have a solution for this issue without changing the shortcut?
You may change the barcode scanner configuration to send some other keys at start.
Most barcode scanners provide a configuration manual where you can set such settings.
Please note that handling specific characters from barcode scanners can cause some trouble when the user changes his scanner or you have multiple users using different scanners.
Related
I'm developing a GUI in Linux (Ubuntu 16.04 - WM: Gnome) using GTK+3 and the graphic library cairo.
After clicked on a push button (Plot), using the instruction of cairo I draw a red square on a new top window where I put a GtkDrawingArea.
In this window I also put a push button (Cancel) that clicked, hide the window. In this way, if I re-push "Plot", the red square reappear.
The issue is the "x" icon present in the top bar of the window.
If (no me) a user push this x, the window disapper and if he re-push the "Plot" an error is reported.
The question is: it is possible avoid this possible cause of error?
(remove this "x" from the top bar of the window or in some way disable its functionality).
I tryed to find alone a solution and the possibility found are:
1 - Remove from the window the property of "decorated".
The top bar disapper (so also the x) but is not possible move the window on the screen
2 - Using the function gtk_window_set_deletable(window, FALSE) (used before to show the window), but the x is always there and pushing it the window is destroyed.
If you think that can be useful, I can report the code.
I'm waiting your suggestion.
Edit:
Now we know what you want to achieve: display a separate window but avoid destroying it so you can display it again. You already have in the "Cancel" button of your secondary window the logic to hide it.
The cleanest solution is to just do the same: when the user tries to close the secondary window, hide it instead. This way the user is not frustrated of seeing something that apparently doesn't work as expected. Hidden or closed, it's different for you but it's the same for the user.
So you just need to connect to the delete-event of that secondary window, and hide it. There's even no need to create a specific callback for that, GTK+ provides it for you: you just need to connect the delete-event to gtk_widget_hide_on_delete. To display the window again, just call gtk_widget_show_all on it.
Original answer:
I realize the plot
"realize" is a term that has a defined meaning in GTK+. Don't use it out of context, and try to use an alternate term if you're not talking about widget realization.
What I would like is to remove this "x" from the top bar of the window
or in some way disable its functionality.
Do you understand this is ultra annoying for a user and defeats a unified user experience? Would you like to use applications that do random different things?
Anyway, one way of disabling the closing button is to connect to the delete-event and return TRUE there to stop the propagation of the event. The button will still be there but do nothing, so you will have to kill the app to exit it.
To make the button disappear, gtk_window_set_deletable will ask the Window Manager to do that, but we'd need some code to know what's wrong with your attempt.
I needed to customize the back functionality of an app because part of its navigation isn't based on different forms, but it's based on changing content in the same form. It's natural to expect, while navigating a hierarchy of products to go back in that hierarchy by pressing the device's back button, if it has one, instead of leaving the current form.
To do this, I've used the Form's setBackCommand() method, which works as expected except that by doing so, it also adds a back command to the title bar of the IOS device in the simulator. I don't want one because I already have an in-app back functionality, and the code in that method is only meant for those that press the hard button on a device that has one. I considered using the CN1 created command instead of the in-app one, even though I'd rather not, but I also can't set an UIID, so it's just an ugly rectangle with the command's name on it. I also tried to apply that method only if UIBuilder's isBackCommandEnabled() was true, thinking that it would target the devices with back buttons, but it doesn't seem to make a difference (and by the wording on the docs, it seems it sets it, instead of just testing it, which I find a little misleading: "Seamlessly inserts a back command to all the forms").
So, how do I set the behavior of the back command for the devices that have it built-in, without adding one to the others?
This isn't ideal but before invoking the setBackCommand call you can check Display's command behavior and see if its COMMAND_BEHAVIOR_BUTTON_BAR_TITLE_BACK.
I wonder how can I get selected text. (usually done by mouse dragging or shift + arrow on text)
From notepad, word, Internet explorer addressbar, etc.
sending WM_GETTEXT just copy caption, and unable to copy selected text while I rename file name on file explorer.
So, I am considering simulating Ctrl+C. but simulating key strokes seems not a good idea. because it will make side effects.(in case Ctrl+C assigned to other functionality)
I tried following code, wishing copy currently selected text into clipboard
OpenClipboard(0);
EmptyClipboard();
SetClipboardData(CF_TEXT,0);
CloseClipboard();
but no luck, it just emptyclipboard.
how can I copy currently selected text?
(simulating Ctrl+c with no unpredictable effect)
thanks!
(my environments are Windows 7, C programming language, winapi)
I'm not sure if there is a general answer because the various applications you mentioned use different window classes.
For Notepad in particular: The display area seems to be a simple EDIT control. You can use the EM_GETSEL message to retrieve the begin and end of selected text, then use WM_GETTEXT to get the complete text. Do not use GetWindowText because it does not work with windows of another process.
In general, you can try using the WM_COPY message. This should place the text in the clipboard. However, the result depends on how that message handler is implemented in the other application.
You are setting the clipboard using SetClipboardData(CF_TEXT, 0) -- MSDN Doc says that if the second parameter is NULL, the window must process the WM_RENDERFORMAT and WM_RENDERALLFORMATS messages; the same article has a comment on how to allocate Global memory, fill it with the required text and pass it on to SetClipboardData().
On Windows XP, it was possible to disable the Start button with the following code:
hTray = FindWindow (TEXT("Shell_TrayWnd"), NULL);
if (hTray)
{
hStartButton = FindWindowEx(hTray, NULL, TEXT("Button"), NULL);
if (hStartButton) ShowWindow(hStartButton, FALSE);
}
For a public-access computer configuration, I need to be able to do this on Windows 7. The Start button must be disabled (not just hidden), and the remainder of the Taskbar must still be visible and usable. Hiding the Taskbar along with the Start button is not an option. Running full-screen is not an option. Using "Start Killer" won't work because it doesn't actually disable the Start button, just hides it (users can still use hotkeys to pull up the Start menu).
I have already tried the method that uses FindWindowEx with 0xC017 as its third parameter and then tries to disable that window. It doesn't work. That method only works if the whole Taskbar is disabled first. What I need is a method that only disables the Start menu, just like the code I reproduced above does in XP.
Any help is greatly appreciated.
The "correct" version for Windows 7 is as shown below:
HWND hStartBtn = FindWindowEx(NULL, NULL, MAKEINTATOM(0xC017), TEXT("Start"));
if (hStartBtn != NULL)
{
ShowWindow(hStartBtn, FALSE);
}
However, this only disables the button, meaning you won't get the glow or other effects by hovering your mouse cursor over it. You can still click the button region on the taskbar to open the menu. Apparently, the click handler is now implemented in the taskbar window itself, not as part of the separate Start button. That's why you have to disable the entire taskbar first, and consequently why most of the solutions you've found online do precisely that.
However, it looks like the "Start Killer" application now has functions to disable the most common hotkeys that trigger the Start menu, namely Ctrl+Esc and the key. You'll find those options by launching the software, right-clicking on its icon in the taskbar, and selecting "Options" from the menu. You can also edit the Registry to disable the Windows key, as described in this knowledge base article. If you wanted to implement this same functionality yourself through code, the only solution would be a low-level keyboard hook that trapped the keypress events that are responsible and discarded them.
Undocumented hacks like this one are given to breaking with newer versions of Windows. I imagine that Raymond Chen would chuckle and say something like "I told you so". Hacking the Windows interface is a fool's errand. Or, as you say several times in the question, "is not an option".
IS there anything in particular about the start menu you need to disable? You may be able to do the same via policy settings or various other file permissions.
Use one of the available group policies listed here.
You did not mention why you want to disable the start button. If you think about what exactly it is that you don't want your users to do instead of telling us the solution you picked for it (i.e., "disable the start button"), you might come up with a much better solution.
For example, if you want to prevent users from changing certain settings, block that, not the start button!
Or if you don't want them to see all the installed apps, hide those apps instead of the start button!
Or...
(I hope you see my point here).
I am looking for an embeddable interactive console. I want the user to be able to type in some custom commands, and the application to write command responses in it. Would be awesome if it would understand powershell or python, ans supports command completion.
I already built my own bash-like terminal, but I do not want to totally reinvent the wheel, so I'm looking for a third-party stable component before going any further with it.
If someone is interested, I found PoshConsole, a powershell console:
http://poshconsole.codeplex.com/
Thanks
PS: you can find a screen of what I am trying to achieve here:
http://www.hiboox.fr/go/images-100/codein,0a2809b63e05c3d0cac678962e0e3d5a.jpg.html
Nothing found since I asked the question, and to stick with the "do it yourself" way of thinking:
I wrote a terminal-like control in .NET.
http://wpfterminal.codeplex.com/
You can see an example in this screenshot (terminal is integrated in a bigger project) :
http://images4.hiboox.com/images/4210/0a2809b63e05c3d0cac678962e0e3d5a.jpg
Basic mechanisms
Actually what I did was to define a lastPromptIndex integer, and everytime a user presses the ENTER key and a new prompt appears, this value is updated.
After that, it's simple, you just need to process any text input before the textbox validates the input. If the textbox caret was located before your lastPromptIndex, you need to raise an error (usually a beep sound) and you must invalidate the text input, so nothing is written in the textbox. I also automatically set the caret position to the end of the textbox, so the user can immediatly input some text.
Extensions
You can enable command completion by looking for an "UP key" input if the caret is before the prompt index, etc. What you need is just to process input events before they are sent to the textbox internal mechanisms. I don't know if SWT controls allow it, but I'm pretty sure they do, like any serious UI system.