I need to do an object browser/manipulator, similar to the one available in TestComplete, that is, list all the objects and their properties in any running foreign application, and being able to alter their properties, all of this during runtime, of course.
While MSAA/IAccessible can read objects, it can only return the visible objects, and not alter their properties as far as I know.
Using the WinAPI I couldn't read objects with no handles, in example, labels.
Ideally, I would like this done in Delphi, but any other language suggestions are acceptable.
Example of what I want to be able to do (This was done in TestComplete):
The task is not an easy one. If you want to do this, you need to use specific approaches of getting the data for every application framework you want to work with (.NET, MFC, VCL, etc.). While some of these approaches are quite plain (e.g. Reflection for .NET and Java), some other can be more complex and not documented like in case of VCL. TestComplete loads its own hooks into the target process memory and retrieve information about this application via these modules.
Besides, as far as I know, TestComplete can read various types of debug information for tested applications and use it when exposing objects along with their members.
Using IAccessible and Win API is an easier way, though not so effective in some cases. You mentioned that you were unable to get any information from labels using Win API. This happens because TLabel objects in VCL applications are not window objects.
Related
I'm implementing a COM shell-extension interface that may be instantiated by different applications. For example, File Explorer might call it during folder navigation, and then my own application might directly call it from an .exe. I was hoping to share some simple and temporary state information across all instances of the interface (perhaps just a string or a vector of strings). I was hoping it would be like a static member variable, except accessible across all applications.
So I was wondering if this is possible, and if so, how to go about doing it. I've been reading about Windows inter-process communications, and it seems like having simple clipboard functionality might suffice, such that each instance could read or write information to a known memory location. But I wouldn't want to use the clipboard specifically, since that's supposed to be called by the user, and I wouldn't want to interfere with the standard copy-and-paste. Also, I'd like to avoid writing to a file because I think that would slow things down too much. Is there another type of IPC that's suited to sharing a variable across all COM instances? Thanks in advance.
There are many methods to choose. Refer to this. You can try to implement the function of simple clipboard. And other methods refering to this.
I'm writing an application in Clojure. The internals are already written, but what I am struggling with now is the interface.
I do intend at some point to use Seesaw for a GUI interface. However, I would also like to provide a text-based interface that can be used in a terminal, for instance.
I chose to try and implement the text-based interface first, and I do have something that works as a menu, per se, but I have been wondering if there are any libraries I could drop in that would make this easier and prevent me from having to write a bunch of tests for something that someone else may have already tested and implemented.
However, despite searching under a number of different terms, I have yet to find anything like what I'm looking for.
Charva does some of what I want but I have no need for a full ncurses-like interface, just something that will display a bunch of choices I can pick from and act on the choice. Plus Charva isn't even a fully-native Java library; it depends on an ncurses shared library, and since I'm going to want this application to be portable, that will create more headaches. Ideally I would like to find something actually written in Clojure so I don't have to write interop code to use it, but I can if necessary.
Am I just not looking hard enough or does a CLI-based menu interface / presentation layer for Clojure just not exist?
I need the main form of the application to perform ClientToParent() and unsuccessful because I'm in a dll and the Application variable is nil. I appreciate anybody's help.
You can't do anything with a form reference across a module boundary. The host application, even assuming it is a Delphi application, has a different instance of the VCL. So you cannot use a TForm instance from the app in the DLL. You could do so if you were using packages.
You could perhaps enumerate top level windows and find the one in your process. That could work but is messy.
Far better would be to expose functionality to allow the host to provide such services. When the host loaded your DLL it would supply an interface which provided the necessary services. It could convert the coordinates as you need, and perhaps offer other services.
One thing I would query though is that you intend to call ClientToParent. This suggests that you have client/parent relationships between controls in different modules. That is only viable if you are using packages. I do wonder whether you are fully aware of the restrictions relating to VCL usage across modules.
we have some class library that will pop up a dialog, is this a bad idea to do so?
Class libraries are meant to consolidate business logic and to reduce code duplication. Dialogs should be displayed into your presentation layer, where it can decide better way to do so.
For instance, if you class library being used into a winform application, that dialog will be different from dialog displayed into an website.
Yes, it is a bad idea. What happens if a windows service is to use your library?
The only scenario I can think of that this would be OK in is if the class library is for visual display components and will only be used in that context (i.e. only contains dialog boxes and UI components).
When writing a class library that is to be used in many different scenarios, you don't want a blocking call that requires human intervention.
You may be able to find out if the session is interactive or not and make a choice on creating a popup, but this is a hack at best.
Your library should bind to as little other libraries as possible to achieve the intended purpose. Unless you library is some kind of gui library, don't use pop up dialogs.
If it is a class library for displaying dialogs then yes. For any other sort of class library then no.
the right thing for the library to do is to take callbacks like "getInformationFromUser" or "showError" or whatever. It is then up the the library caller to decided how that is done. Or for reporting errors it should raise an exception or return an error code.
For a library to show the dialog itself it has to make a large number of assumptions - that the library is being used in a GUI program, what GUI framework is being used, what language the user understands etc. This is wrong, wrong, wrong.
It very much depends. If this class library contains many other GUI classes, then maybe. If this library contains domain objects, then this sounds like a bad idea.
I think it's a bad idea.
But in certain cases you might want to make UI logic reusable. In that case try to pull out user-interaction code in a separate library.
I'd say bad idea. For an example of a non-visual library class, take a look at QFile. When using it, it reports error status back as return values (e.g. if(!file.open(mode...))), and then keeps the last error both as an application friendly enum (http://doc.trolltech.com/4.6/qfile.html#error) and as a human readable error string (http://doc.trolltech.com/4.6/qiodevice.html#errorString) which your application can use to easily pop-up a dialog, print it to a console, or add it to a log, etc.
As you can see, this approach gives the application the power to decide how to handle the error message - instead of the library making what it feels is good for the moment.
In theory, if it's just used in one specific application that you know will be only used with a GUI, then there's no harm in it.
But the harsh reality is, libraries will have the tendency to turn more and more generic and you'll need them in all sorts of applications, not just GUI-based ones. So you might as well plan ahead and ban dialogs in the library and just handle the error reporting some other way.
Here's what I think:
It depends to the main purpose of your class library if it's a UI module that provides some UI features then there should be some dialogs and forms and etc. but if it's a library that is supposed to provide some services (business or data access) to other parts of your application there should be no UI element in your library.
I'm starting to develop a Windows service. I want to use some classes from my own, that has little dependencies to some MFC classes like CString, CSocket, CArchive, CMemFile and CObject. MSDN says you need to be very careful about which pieces of MFC you use in the Windows service, but don't specifies it and don't describes the problems that can occur.
My questions are:
what pieces of MFC can be used?
what problems can I expect, by using MFC?
which parts of Windows service are critical for MFC use?
is it advisable to use ATL instead of MFC for Windows service?
I'm not sure what they mean in teh MSDN article. As long as you don't use any of the GUI functionality you'll be fine - but that's a general design issue when developing services.
That being said, ATL has functionality specifically designed for building services IIRC so you may be better off using that.
To answer your questions (to the best of my knowledge):
1) the ones you specify are no problem.
2) I guess they mean synchronization issues with UI components. As long as you don't use any CWnd-derived classes you'll be fine.
3) don't understand the question.
4) See before, plus ATL is more lightweight so you'll have to distribute less, and provides build-in functionality that'll make it less of a pain to develop the service. See e.g. CAtlServiceModuleT. You'll still be able to mostly use your own classes, as CString is shared between MFC and ATL nowadays and ATL has classes for socket programming and memory file mapping itself. It doesn't have an equivalent for CArchive, and I'm not sure what functionality you use in CObject so I can't say whether there's an equivalent in ATL. So to conclude, I'd say 'yes' to this question.
(I know this answer is a bit late and this question was already answered but MFC in services is a sore spot for me...)
CSockets, far as I recall, require a Window. It makes an invisible one in the background. I found out this the hard way when I tried include some pre-exisiting MFC code into a windows service. Maybe this was only required if you accepted socket connection - I can't recall? But it did not work! (How exactly I wasted so much time doing this w/o realizing this limitation is a long story)
CObject? If you need the runtime class id stuff use RTTI (dynamic_cast, etc...)
CString, I like CString, I know it's shared with ATL now, not sure if you pull it in w/o MFC or ATL included... You could use std::string. Also, I recall someone created a derived std::string that provided the same methods as CString.
(EDIT: found the code - man!! that's a blast from the past...)
CArchive, CMemFile: do you really need these?
Anyway, as Roel said, ATL may be more helpful. I wouldn't use MFC in a server-side application (ever!) ATL? Maybe. If I needed COM, defiantly. No COM but for CAtlServiceModuleT, etc... maybe....
And another bad thing about MFC in services that I have just experienced while trying to turn a regular MFC-ATL app into a service: The use of AfxConnectionAdvise() is actually useless without a Window procedure. The threads in my service are just regular non message-pumping threads. I believe this is why I never get events fired from another COM server I have developed. That other COM server hangs on Fire_xxxEvent(), causing a big mess in the whole system.