i created the app and all the plugins written for it should draw on special place on my form that will be random or specially selected for plugin, so everytime the coordinates is random. Also they should use standard windows GDI functions like Rectangle(), FillRect(), TextOutA() and other.
What is the better method to accomplish this? I know i should make drawing engine inside my program, i have 2 choices: to use named pipes or to use windows messages. Maybe someone have another methods implemented and tested?
In order to use GDI functions, they need access to an HDC handle. If your app sets aside a TPanel or other suitable windowed container for drawing, then it can pass the container's HWND handle to the plugin and then the plugin can obtain the HDC manually via GetDC() or GetWindowDC() when needed. If you chose to pass the actual HDC to the plugin instead, then you can set aside a TPaintBox or other suitable non-windowed container instead, which does not require a dedicated HWND and associated resources.
Related
Is there a way to detect input areas such as textboxes and checkboxes within an application? I want to label each input area with a number so I can jump between input fields with AHK using my keyboard.
For example: Once the script is activated and active window is Google Chrome, Chrome could have its address bar labeled #1. When I press "1", the cursor will be directed to that area.
I'm basically trying to create a workaround for applications that are not very keyboard friendly.
Most Windows applications use standard windows elements.
For these...
https://autohotkey.com/docs/commands/WinGet.htm - with the ControlList parameter, gets a list of all standard controls.
For those:
https://autohotkey.com/docs/commands/ControlGet.htm - can get the type of control, and
https://autohotkey.com/docs/commands/ControlGetPos.htm - can get position and dimensions of the control.
Some can also be controlled through COM: https://gist.github.com/kheybot/7026077#automation-of-office-applications
Commandline and console programs can sometimes be communicated with directly, using the standard streams (STDIN, STDOUT, STDERR, LPTn, PRN, NUL), or you can communicate with the terminal that displays the program using COM or WSH:
https://gist.github.com/kheybot/7026077#interact-with-command-line
This is important for a lot of legacy data-entry programs.
Browsers (eg Chrome), unfortunately, can't use these heavyweight components, because there may be far too many on a page, but there are other options for communicating with them, such as COM, DDE, etc to communicate with the DOM:
https://gist.github.com/kheybot/7026077#browser-automation
For a web browser, I'd be inclined to go for a hybrid approach, combining AHK-handling of the web browser's input areas (address bar, etc) with a Greasemonkey/Tampermonkey script to handle input fields within the web page itself - the Javascript will be better able to handle input areas using the DOM than any screen-scraping software could. There's also the possibility of using a functional-testing suite like Selenium for automation, and using the browser's plug-in functionality to write an extension to handle its UI.
This would mean that you now have TWO programming problems, of course...
Java applications, Flash applications, HTML5 applications, some graphic design software, and just about all computer games are essentially just graphics, with no way of externally identifying controls.
For these, you have to use basic screen scraping techniques: http://www.autohotkey.com/docs/commands/ImageSearch.htm and http://www.autohotkey.com/docs/commands/PixelSearch.htm to identify specific areas, which can only really be done by individually programming the specific control.
One option for generic detection, though, is to have something that detects shadows (drop shadows, buttonized components, etc) and allows you to tab between and send a click to the components detected that way. Unfortunately, modern flat design meant this won't always work, so you could also try searching for flat-colored rectangles... except sometimes they have curved corners. Because graphic designers hate people.
At this point, you will hopefully see that what you have here is an infinite rabbithole of fractal complexity.
You can make a simple ControlGet solution which doesn't work for a lot of applications you would use regularly... or you can create a hybrid approach that targets many applications individually, while also trying to have a generic solution for unrecognized apps.
If you are creating this for your own use, I'd say aim for making it work with the apps you know and use regularly, and that should be enough.
If you're writing it as accessibility software for others to use, I'd say aim for having it user-configurable for each application: let them control what input element they want to click, and in what order, because auto-detection will never work perfectly, and will only rarely pick the ideal solution.
The answer is yes, if the number of check boxes and their position in the application is fixed and you know on which machine the automation takes place.
Please research ImageSearch on how to locate them from screenshots.
If you know the X/Y position of the checkbox in the window, you can also use PixelGetColor to check if a check is visible or not.
You should also examine your application with the included AutoIt Spy. This program shows you, what it can see in the application window.
To get your labelling, checkout the Gui commands. If you make you gui transparent and don't give focus, you can write labels on top of the application.
I want to set image to button:
GtkImage* imageForButton = gtk_image_new_from_resource("which path is here?");
GtkWidget* btn = gtk_button_new();
gtk_button_set_image(GTK_BUTTON(btn));
How to make it work with embedded resources?
I have resource.h/resource.rc, gonna try to use MakeIntResource, but I don't see any use of it for GTK.
GTK+ doesn't support Windows resources (at least as far as I can tell). Instead, it uses its own cross-platform resource format, GResource. The easiest way to get embedded resources working is to use this. It isn't compatible with Windows resource editors, and requires generating an extra C source file, but it should work fine so long as you use GLib or GTK+. You should have the GResource compiler as part of your GTK+ install (but I'm not 100% sure). And if you go this route, you'll be able to keep using PNG files. (I don't know how to use PNG files with Windows resources, if that even is possible.)
If you insist on using Windows resources, though, I can think of one possible way to do this, though this isn't the only one: use the Windows API resource functions to load an HBITMAP from your resource, call GetObject() to get the BITMAP structure from the HBITMAP, and then calling gdk_pixbuf_new_from_data() with the appropriate fields from the BITMAP structure as parameters (rowstride == BITMAP.bmWidthBytes). Good luck!
Now, I have my simple project on changing the color image into white&black image using CUDA-C.
But I got a problem with importing/loading a bitmap image into program. I don't know how to import it.
So...
CUDA-C have a specific function about importing/loading bitmap image?
If yes, what is it and how to use it?
If no, how do you do with importing/loading bitmap image?
Thank you.
There's really nothing that is CUDA-specific about loading a bitmap image into an application.
If you have a preferred method for loading a bitmap image into an application, you should be able to use it with a CUDA app. You will obviously be loading the image into the host application space first. After that, if you want to transfer it to the device, you can use any of the standard methods for transferring data to the device to accomplish this.
CUDA (i.e. the runtime API) doesn't have any specific functions for importing/loading a bitmap image
-
There are many ways to load an image. If you are already using OpenGL or DirectX, then you will want to use a method associated with one of those APIs, and then use the appropriate interop API within CUDA to manipulate the object.
If you want to import a bitmap image directly into a CUDA program without using a graphics API, take a look at the CUDA samples, as a number of them do this and provide helper functions that you may want to re-use.
For example, the dct8x8 sample provides a file called BmpUtil.cpp which contains a number of useful bitmap import/handling routines, and the dct8x8 app (dct8x8.cu) shows how these may be used directly in a CUDA app.
I'm writing a plugin for an application that uses Direct3D (9.0c) as its renderer. Not many things are exposed to my plugin, however I do have access to the IDirect3DDevice9 interface. Using the pointer to this interface, is it possible to enumerate the textures that have been allocated?
Specifically, I'm needing to find the render targets that the application uses for a render to texture so that I can gain access to its depth buffer for use with my custom shader.
Thanks,
Brian
If you have access to the IDirect3DDevice9 at any time, you can just use GetRenderTarget method to obtain current render target - http://msdn.microsoft.com/en-us/library/windows/desktop/bb174404(v=vs.85).aspx . If you need an access to the depth buffer then things get complicated. If the application writes the depth to a separate texture, you can get it. If the application uses hardware depth buffer, it's rather not possible to read from it.
Basically, I have two applications that run sequentially (second is started by the first, and the first exits immediately after.) I'd like to pass ownership of a window the first application created to the second application. The actual contents of the window don't need to be passed along, it's just being drawn in by DirectX.
Alternatively, but less desirably, is it possible to at least disable the window closing/opening animation, so it at least looks like the desired effect is achieved?
(This is in C, using the vanilla Win32 API.)
Instead of separated application make a DLL that will be loaded by the first application and run within it.
I suspect that you're going to run into problems because the WindowProc function is located in the memory address space of the program that you're closing.
Also, a quick look at the second remark at the bottom of the documentation for RegisterClass doesn't seem to offer up much hope.
The only work around that I can suggest for what you've described is to not close the first application until the second application is finished with the window in question.
you can use API hooking to make your DLL capture API windows calls sent by the application window and respond as if your DLL is the windows DLL
for more information about hooking check :
Hooks Overview