I try to fill the qlineedits of an external application. It has Qt5WindowIcon class, and I was able to find that it receives messages using WinAPI, it uses PeekMessage, PostMessage and DefWindowProc, but the trick is that it doesn't have any child controls this can be seen in Spy++ and also I tried manually with EnumChildWindos and it always returns false.
Are the Qt controls somewhat different and independent from WinAPI? I heard there are so called alien widgets, are they painted manually in user mode? I also tried setting breakpoints on GetWindowText, SetWindowText, GetDlgItemText, SendMessage+WM_GETTEXT , and I never got any bp hits, seems like Qt doesn't use this API to set/get text from QLineEdit.
Is there any way that I can find control id? Or the only option would be code injection with QLineEdit methods hooking?
Related
I am coding a test application for a windows CE device. This is the first time I am programming for a handheld device. I use MFC VC++ on Visual Studio 2008. I have found that there are many restrictions in the controls and what I could do with them when running the program on a handy versus when I run a similar program on a desktop computer.
Now, the device I am currently deploying my test program to, does not have a touchscreen and has few extra keys other that the numberpad 0-9 keys. So, I have to do with a simple GUI that uses keydowns to call specific functions like add, edit, delete etc... It also forces me to use separate dialogs for each of these functions so as to avoid unnecessary mouse cursor usage.
This leads me to my current problem: The 'ADD' dialog of my test app adds some user data to a CListCtrl that is on the 'MAIN' dialog. The 'EDIT/DELETE' dialog is to allow the user to select the desired data from its own CListCtrl and press the "ENTER" key, which thereby deletes the selected data from the 'MAIN' dialog's CListCtrl. Thus, both the main dialog and the 'EDIT/DELETE' dialog have CListCtrl with the exact same data. So, instead of having to use 2 separate list controls and using loops to copy the data to and fro among them, is there a way in which i could use the exact same CListCtrl (one and only one instance of the CListCtrl exists), but display it on 2 separate dialogs? This would remove all the copying code, as well as halve the amount of data in memory.
I tried passing a pointer to the MAIN dialog's CListCtrl to the 'EDIT/DELETE' dialog in hopes that I could redraw the control there, but in vain. I could call the RedrawWindow, RedrawItems commands, but they seem to have no effect in the 'EDIT/DELETE' dialog (I think it is because the control itself is not present on the edit/delete dialog). Any other suggestions?
You could temporarily change the parent of the ListCtrl using CWnd::SetParent to the EDIT/DELETE dialog, and set the position with CWnd::SetWindowPos to where you want to have it. When the dialog gets closed, set the parent back to the MAIN dialog.
As we all know, EVT_CHAR is a basic event which don't propagate to wxTopLevelWindow(wxFrame and wxDialog).
But I have a wxDialog without any wxWidgets controls on it, and need to handle user keyboard input (handle EVT_CHAR event).
I saw the wiki about catch key events globally, but it's not work on EVT_CHAR event as EVT_CHAR event need to be translated to get user input
And I have try to have wxDialog a hided children wxWindow which foward EVT_CHAR to its parent wxDialog. It works on Windows platform, and not on OSX which is my target platform.
Is there a way to implement it ?
Why do you need to handle all keyboard entry in the dialog itself? There are two typical cases for this that I know of: either you want to handle the key presses in several different controls in the same way, or you need to handle some particular key press (e.g. WXK_F1) in all controls. The former can be done by binding the same event handler to several controls. The latter -- by using accelerator table with an entry for the key that you want to handle specially.
Finally, I implemented what I want according to this:
http://trac.wxwidgets.org/ticket/15345
In wxWidgets 3.0, wxNSView implementes NSTextInputClient protocol, which makes every widgets can handle EVT_CHAR correctly.
But EVT_CHAR still cannnot be handle by wxDialog or wxFrame, because of some call of IsUserPanel() function. So I commented some call of IsUserPanel to make it work for me.
I'm migrating an application from a homegrown UI to Qt. One of the most important controls is the property panel, which takes an object that implements my reflection API's interface and spits out a dialog box containing editors for all the properties.
I've written an implementation of QAbstractItemModel for my property system and I've written a few handlers for various types inside of a QTableView. I've also written a QItemDelegate to create editors for the properties.
The trouble is that I'd like the editors to hang around, rather than be strictly popups. This is so that they can handle the rendering of the property, require less clicks to operate and also not disappear as soon as something else gets the focus, such as my colour button - the editor (which has the slots listening for colour changes) disappears as soon as the colour picker dialog appears, which means that nothing is then listening for changes.
I can't find any options for making the editors persist. Am I barking up the wrong tree here or is there a more appropriate way of doing this? I've tried to do things the 'Qt' way but I'm already hitting brick walls.
Thanks,
There is the QAbstractItemView::openPersistentEditor() method.
I want to make a custom made component (a line chart), that would be used in other applications.
I don't know 2 things:
Where should I use (within component class!) the methods for drawing, like FillRect
or PolyLine? In OnPaint handler that I should define and map it in MESSAGE MAP? Will
it (OnPaint handler) be called from OnPaint handler of the dialog of the application
or where from?
How to connect the component, once it is made, to the test application, which will
for example be dialog based? Where should I instantiate that component? From an
OnCreate method of the MyAppDialog.cpp?
I started coding in MFC few days ago and I'm so confused about it.
Thanks in advance,
Cheers.
Painting the control is handled exactly like it would be if it wasn't a control. Given that you're using MFC, that (at least normally) means you do the drawing in the View class' OnDraw (MFC normally handles OnPaint internally, so you rarely touch it).
Inserting the resulting ActiveX control in the host application will be done like inserting any other ActiveX control. Assuming you're doing your development in Visual Studio, you'll normally do that by opening the dialog, right clicking inside the dialog box, and clicking "Insert ActiveX Control..." in the menu that pops up. Pick your control from the list, and it'll generate a wrapper class for the control and code to create an object of that class as needed. From the viewpoint of the dialog code, it's just there, and you can use it about like any other control.
For create new component in MFC, you must create a class from the window class (CWND),
after that you can have your MessageMap for the component and your methods and also can override CWND::OnDraw method to draw the thing you want.
Before that I suggest you to take a look to device context
http://msdn.microsoft.com/en-us/library/azz5wt61(VS.80).aspx
Good Luck friend.
I'm creating a plugin framework, where my application loads a series of plugin DLL's, then creates a new window and pass this new window's handle to the plugin. The plugin can, then, use this handle to create their own GUI.
Everything seems to be working very well. The only problem is that when I press TAB on a plugin widget (An editbox, for example), it doen't jump to another widget. I figured out that some Windows messages are passed, and some others aren't. The WM_KEYDOWN is passed for other keys, because I can type on the editbox, but this message doesn't handle TAB key.
Hope somebody has a hint.
I'm using Borland VCL with CBuilder, but I think I could use any framework under WIN32 to create these plugins, since they never know how their parent windows were created.
It's very complex matter indeed.
When you hit TAB focus jumps to another control only when these controls belong to a Modal Dialog Box. In fact there are some buttons like ESC, LEFT, RIGHT, DOWN, UP, TAB which modal dialog message function treats in a special way. If you want these keys to behave in similar way with modeless dialog box or any other window you should change you message processing function and use IsDialogMessage inside. You'll find more information about IsDialogMessage function in MSDN also to better understand this stuff you may check as well Dialog Boxes section.
And, as was mentioned before, you should set WS_TABSTOP and WS_GROUP styles when needed.
Good luck!
I believe you'll have to take the following steps:
Subclass your edit controls (and other controls as needed).
Capture the WM_KEYDOWN message in your edit control's WndProc.
Check to see if the shift key is currently held down (using GetKeyState or similar).
Call GetWindow, passing in a handle to your edit control and either GW_HWNDPREV or GW_HWNDNEXT depending on whether shift is held down. This will give you the handle to the window that should receive focus.
Call SetFocus and pass in the window handle you got in step 4.
Make sure you handle the case where your edit controls are multiline, as you might want to have a real tab character appear instead of moving to the next control.
Hope that helps!
I believe you suffer from having a different instance of the VCL in each of your dlls and exes. Classes from the dll are not the same as the ones from your exe, even if they are called the same. Also global variables (Application, Screen) are not shared between them. Neither is the memory since they both have their own memory manager.
The solution is to have the dlls and the exe share the VCL library and the memory manager. I am not a BCB developer, but a Delphi developer. In Delphi we would just use the rtl and the vcl as runtime packages. Maybe you could do the BCB equivalent.
A DLL has its own TApplication object.
to provide uniform key handling. when the DLL Loads.
assign the DLL::TApplication to the EXE::TApplication
Be sure to do the reverse on exit.
--
Michael