In an c# app, I am performing a EnumWindows of all windows on the desktop and in the callback I get the window title for each window. One 3rd party app in particular can be run in ansi or unicode mode, is it safe to use GetWindowTextW all the time even though the app is running in ansi mode or do I need to be able to detect whether unicode mode is enabled for all external apps in order to determine which GetWindowText I need to call? The problem I'm hitting is we have been using GetWindowTextA even on the unicode apps and has worked up until now. It fails to return the correct window title for obvious reasons when there are chinese characters in the title bar.
The wide functions are always the best choice (assuming you don't care about Windows 95/98/ME).
The window text can come from two places:
Unicode text "stored internally in the HWND". Most top-level windows store their text here. GetWindowTextW is always able to retrieve this text.
Some applications dynamically handle the WM_*TEXT* messages. The window manager handles character conversion for you (SendMessageA vs SendMessageW) so you don't have to think about it.
GetWindowTextW will not send the WM_*TEXT* messages if you call it on a window in a different process. If you want to always get the "correct" text of windows in other processes you manually have to call SendMessageTimeoutW(..., WM_GETTEXT, ...) first and if that fails with a timeout, fall back to GetWindowTextW.
Related
I am developing a simple chat application which works in LAN. I have a problem in ALt+Tab.
When I open 2 applications (One is mine and another one say Firefox), now it switches properly between two windows when I press Alt+Tab.
Now I will minimize firefox. So now my app is the only one in foreground. Now if I press Alt+Tab, firefox comes foreground which is not expected (or I dont expect).
How to make Alt+Tab not work when all windows are in minimized state ?
I am using vb.net but c# is also OK for me and for example I have given firefox; there may be n number of windows in minimized state.
Please help me.
Pressing ALT + TAB in Windows (or other OS) is supposed to switch between every active application that is running and has a top-level Window. So the behavior you are describing is actually working the way it is supposed to.
More on Wikipedia about that.
However, it is possible to hack this behavior by capturing the ALt-Tab event. It is actually used by several remote control application so they can transmit commands from one computer to another.
Here is a start up guide, but beware that you get into Windows weird APIs and low-level functionnality. Use at your own risk...
I have been charged with the task to send data from COM 1 to COM 2 in Windows CE 4.2. A running application takes data from COM 1 and displays it to the user in a form (textbox I assume). I then have to take that data and send it out COM 2. COM 1 is being used by the program displaying the data and I know of no way to hijack COM 1.
I figure trying to do a screen scrap would be the next step. Unfortunately this is compact framework and an old version at that and from a lot of research it seems managed code is out of the question . Many of the API functions I would use are not available; FindWindowEx for example.
Here is where I am at now. I have created two projects. One runs with a TextBox and some wording. A separate application runs and tries to read the text in that TextBox. I have been able to find the running process based off the name of the form using FindWindow API. Using code I have found on this site I have even been able to enumerate through the controls of the form. However my TextBox is never found and many of the controls that are found where never placed on the form by myself (listbox, button). I assume those are the form's initial controls.
Does anyone have any experience with this? Currently this is in C# but VB or Visual C++ will be fine. Even if you have any ideas on a third party application. BTW I am not given the option to upgrade to a higher version of compact framework.
Thank you.
An update I just found out about. It does not look like I only screen scrape only new data but instead have to screen scrape the entire screen and send it out COM2. Someone will scan a barcode and I will send out all screen data through COM2. The data may include a picture etc.
For a native C application I have one sceleton that enumerates all child windows and controls inside a dialog: http://code.google.com/p/rdp-auto-login/source/browse/trunk/rdp-auto-login/tscDialog.cpp. See ScanTSCWindow and the results found in the comment "TSC dialog elements".
I started with remote spy and looked thru the RDM window to find the CtrlID values. There is also a nice tool called zDump (http://www.hjgode.de/wp/2009/06/11/zdump-take-a-look-inside-windows-ce/) that runs on device and enables you to look at window elements.
The theory is that every element in Windows (either Mobile or desktop) is a window. Windows are accesible by there window handle. The handle is assign by the OS during CreateWindow/Ex. Inside dialogs, elements can be identified by there control ID (a resource value), the window class (ie "EDIT", "LISTBOX") and window text and internally by the window handle at creation.
The problem with Compact Framework apps is that they hide many of these basics and dialog (Form) elements can not be easily identified from another process.
As you say you are not able to capture COM1, what is, if you stop the application and then open COM1? As knonw, normally on one application can access a serial port at the same time. You can then read the serial data directly and do not need to access a foreign window.
There are also drivers that enable port mirroring or multiple access. Even for Windows CE based OS (ie http://www.virtual-serial-port.org/products/serial-splitter-mobile/).
If the application is a compact framework one you can take a look inside the code using .Net Reflector or similar .Net decompilers. I use that often to mimik or learn from other apps.
You say "I have been charged with the task to send data from COM 1 to COM 2 in Windows CE 4.2. A running application takes data from COM 1 and displays it to the user in a form (textbox I assume). I then have to take that data and send it out COM 2. COM 1 is being used by the program displaying the data and I know of no way to hijack COM 1." and if you do not start the other app you can write your own and do not need to parse the foreign app.
Possibly you can post the other app or more details of what it does what you can not do.
EDIT/UPDATE:
as we now know it is Intermec TE2000 (terminal emulation) the answer is to use the XMLRPC interface provided by TE2000. The interface is able to call back a function hosted by an xmlrpc server and send all screen content (text, fields and attributes) on screen changes. I have working c++ stl windowsce code for that.
If the device is connected via network, the xmlrpc server can even run on a PC.
As TE2000 does use native drwastring API you will not success in reading texts from the window. If you screen capture the window, you will have to do OCR on the image. XMLRPC does avoid all this.
UPDATE2:
I finished a class lib to get async screen updates using TE2000 xmlrpc: see https://github.com/hjgode/ITE_xml_rpc/tree/master/XmlRpcCS/XmlRpcCF
and http://community.intermec.com/t5/Thin-Client-Based-Development/Printing-CV60-Screen-Windows-CE-4-2/m-p/28663/highlight/false#M473
I'm writing a .NET 4.0 application that simply accepts input into a TextBox, processes it and then sends it off to a database. This app is intended to work with USB barcode scanners.
I have a requirement to ensure that the input from these barcode scans is processed by this app. I have been asked to ensure that this app stays activated and focused at all times as the laptop it will reside on has no other requirements other than to power and accept input from a USB barcode scanner.
I managed to achieve this myself by using a System.Windows.Forms.Timer that calls this.Activate() on a set interval, or better yet;
protected override void OnDeactivate(EventArgs e)
{
BeginInvoke((Action)this.Activate);
base.OnDeactivate(e);
}
Whilst these methods work fine on my Windows 8.1 Development machine, I can't get this same code to work on a Windows 7 OS (I've tried numerous boxes as well as VMs). For the Win7 machines I can see that this code is executed fine, but I just cannot get my app to Activate again.
Could anyone please advise as to why I'm seeing this behaviour?
Many thanks!
Windows only permits the application that owns the foreground window to bring another window into the foreground (either one of its own or belonging to another application). A background application can't bring itself into the foreground. This is a deliberate design choice (introduced circa Windows 98, as I recall) to prevent background applications from interrupting what the user is doing - particularly to ensure that keyboard input goes to the right place and doesn't accidentally fire actions that the user hadn't intended.
This constraint is documented in the SetForegroundWindow documentation:
The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
• The process is the foreground process.
• The process was started by the foreground process.
• The process received the last input event.
• There is no foreground process.
• The process is being debugged.
• The foreground process is not a Modern Application or the Start Screen.
• The foreground is not locked (see LockSetForegroundWindow).
• The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
• No menus are active.
Source: SetForegroundWindow function (Windows)
If you need to be sure that input from a barcode scanner goes into a particular application, you should look into keyboard hooks, if the scanner is configured for keyboard emulation, or whether the scanner supports another API to allow direct control.
For example, the scanner may support the National Retail Federation's UnifiedPOS standard. Microsoft have provided a library, POS for .NET, which allows UnifiedPOS devices to be controlled from .NET.
That's an illegal action. You're stealing control from the user, which is forbidden in the desktop ecosystem. The user should always be the one in control. Windows Vista+ started paying a lot more attention to things like this.
The proper thing the OS is supposed to do is notify the user you want his attention (e.g. flashing the window in the taskbar), it must not actually activate your window. Every time the OS allows you to steal control from the user, it's considered to be a bug, and usually must be fixed.
Maybe you want to replace the default Windows shell instead? That will allow you to simply have just one application running anyway, and when it's closed, it will restart the machine...
Barcode scanners typically transfer their data as if some user would have typed it by using keyboard. This lead to a false assumption that you need to have focus and active window all the time.
However, you could use technique from stone age called keylogging (usually with the word trojan in front). This is achieved by setting keyboard hooks in windows based system. Then your application can have all the input.
It's done by using SetWindowsHookEx. I still have windows XP software which uses hooks and it seems to work under Window 8.
The problem to determine when it's a barcode scanner and when user is typing password into login form of another application I leave at your disposal =P.
Just the functionality of intercepting the keyboard entry , transforming it and sending it back is required.eg if user press a i wold like to send e etc.
To make a application that accepts the entry from keyboard modify it and send it to the active window (may be application like word, excel,notepad windows screens ) etc.
The feature is just like google's transliteration application for windows .
I would like to do it in c# .
I think this involves hooking in the keyboard and sending keys (like sendkey in vb) to the current window.
The working is just like Google transliteration .However the logic for transformation is quite different.
I'm not sure what the question is exactly, so it may get closed for being too vague. However, it sounds like you'll have to buffer all of the keystrokes, send words or phrases to some service asynchronously to be transliterated and then push them back into keyboard buffer with something like sendkeys as you mentioned. The problem is that if your app has focus, we don't know where the user wants the transliterated text to show up, and if the app such as Word has focus, it will receive both the real keystrokes and the transliterated text, which will then be mixed together (a mess). Seems better just to transliterate chunks of text rather than trying to interfere with the keyboard buffer - besides, backspace, undo, etc. will be nearly impossible to honor.
You need to write a dll which uses Windows Text Service framework or legacy IME framework .
This dll will get loaded into langauge bar and when you will activate it ; your code , which has implemented a set of APIS required by TSF or IME framework , will get the key event , You can then pass it to your code which translates it and passes a string back to you.Another of your implemented API can then input to the Current text editor of the windows Application.
Currently our software is running on AIX Unix machines, but we use Windows boxes running Exceed to display the UI in X-windows. I'm writing a Windows application ( modernizing the UI in C# ), but some of the legacy windows still need to be displayed in Exceed. When a user clicks a button on my windows application, it sends a message to the Unix server which displays the X-window. My problem is that these X-windows are not getting focus, so they are popping up BEHIND all of my .NET windows/forms.
A user of this software can easily have 5+ windows forms open at any given time, so it is a big inconvenience if every time they want to display a legacy X-window, they have to minimise all of the .NET windows. What is the best way for me to solve this? Is there a way for me to give Exceed focus so that it brings the X-window to the top? I tried using Application.OpenForms, but calling .SendToBack() on each form didn't help me.
If the pop-up windows are coming from a process other than the Windows app which you're creating, you'll probably need to resort to a hack. Microsoft put code into WinXP to prevent apps from being able to throw their windows in front of everything, unless it's part of the app the user is working on. To do this, you need to monkey with the ForegroundLockTimeout registry value, and the Windows APIs to pull a window to the front.
More info:
http://social.msdn.microsoft.com/forums/en-US/winforms/thread/54826e98-9faa-4457-ba1d-b645af88170b/ (The last entry contains the conclusion, but you'll need to read some of the previous entries. I also suggest you set the ForegroundLockTimeout to zero, do the switch, then set ForegroundLockTimeout back to its previous value.)