Assign a window handle value to an application

[AutoitMike]

In an Autoit application I am sending text to a field that is the window handle value. That application stores this value in an XML file.

Of course I cant open up that XML file and write to it because the app has that file open.

So now I am using "Send" to send text to the app.

It would be sooo much cleaner if I could update the associated XML file before the app is opened with a valid window handle value.

When the app is opened, the window handle is the value that I somehow created.

Is this possible ? (Win 7)

Thanks

Edited May 11, 2023 by AutoitMike

[mistersquirrle]

The question doesn't make sense to me... maybe you can let me know if this is wrong, just rewording it as I understand it.

You get a window handle for some window, and want to pass that handle into another app through the XML file. However because the app is open, it has a lock on the XML file and you cannot write to it. So you're somehow inputting the window handle into this other app with "Send", and it's able to accept it that way. But you prefer to write to the XML file, if possible?

What is this other app? Could you just close the app, write to the XML, and then re-open the other app?

If the other app is something you made with AutoIt, I'd recommend looking into IPC options: https://www.autoitscript.com/wiki/User_Defined_Functions#Inter_Process_Communications

If it's not something that you created, maybe you can look into ControlSend instead, or see if there's some API or possibly COM interface that you can call from AutoIt.

Otherwise, it's hard to say what you can do or what other options there are without more information.

[AutoitMike]

Mistersquirrel

Is not true that if get the handle to an apps window, close that app, repen that app, wouldnt the handle be different now?

At a later time a different app needs to know the handle value for this app in order to select, activate the correct app because there is always multiple instances of this app existing.

[Danp2]

FWIW, I also found your question confusing. Which app is using the XML file? Also, from where does the window handle come? With which window is it associated?

[mistersquirrle]

4 hours ago, AutoitMike said:

Is not true that if get the handle to an apps window, close that app, repen that app, wouldnt the handle be different now?

At a later time a different app needs to know the handle value for this app in order to select, activate the correct app because there is always multiple instances of this app existing.

That is true, the handle will be different. So you're saying that you need to use AutoIt to get the window handle for another program and feed that window handle back into itself? Why can't this program get its OWN window handle???

Please, if you want more help, tell us more about what you're looking to do.

What is the program that you're trying to pass the window handle to. Why does it need it. Why can't it manage or get its own window handle. What are you trying to do. Show us your current code. Screenshots. The XML. Something.

[AutoitMike]

OK,

I will explain in more detail.

A home inspection app I will call HG stores all information in an xml file called report.hg5

It also adds a record to an SQLlite database that stores various data. There is a field that I can use to store whatever I want called “Status”

After an inspection is made there are pictures to import into the application. A poorly written , tedious process.

I have a AutoIt app that automates this import process. It has to know Which instance of HG to interact with. I cant 100% rely on the title bar being unique. So if it knows the window handle value, boom , we got it.

I have a Autoit app that automates the process of starting a new report using data from an attached .pdf from an email (1280 lines of code, 12 “includes”)

Currently I have to use a screen input method to store the windows handle value. This value is in both the xml file and the SQLlite database record.

BUT, I would like to store the handle directly in to the xml file and update the record in the database. And to do this I have to close the hg app, update the files and then reopen it. To do this I need to know what the handle WILL BE.

Or, would the window handle value be the same after closing the app and reopening it?

I hope this explains the situation better.

Thanks for your inputs

Edited May 13, 2023 by AutoitMike

[Danp2]

Your process is still murky to me --

• How do you currently obtaining the window handle?
• While the HG app is running, are you able to use AutoIt to retrieve the handle from either the XML file or the SQLite database?
• Once you have the handle in AutoIt, how are you using it?

I don't understand why you would want to directly store the handle in the XML and database files. Doesn't the HG app automatically update these values when you launch it? Could you use WinList to get a list of matching windows and let the user pick the target window from a list?

Still confused 🤨

[mistersquirrle]

I'm also still confused. I don't really understand why the window handle is *so* important... Sure, to make sure that you're inputting and interacting with the 'correct' window for the entire input process, but why does the HG app need the window handle? Is the window handle in the XML and SQLite just to make sure that they're linked by a common key? Could you just use anything, like a timestamp or GUID?

For the XML, if HG has it locked, there may be ways around unlocking it so you can write to it, but I'm not sure about that. (Maybe something like https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-unlockfile)

For SQLite, have you tried using the SQLite UDF? You should be able to write to the database even while HG is open, unless it's doing something weird and locking the database. https://www.autoitscript.com/autoit3/docs/libfunctions/SQLite Management.htm

Otherwise, could you just get the window handle, whatever other information you need, and write to the XML and SQLite database after you close the HG app? Do whatever you need in the app, close it, XML file is now available to write to, so write what the window handle was (since you AutoIt still knows what it was) or whatever else you need.

[AutoitMike]

I not sure how to answere this question any differently.

I the most simple terms:

1. There are multiple instances of an application that will be interacted with by Autoit at some time after each instance is created.

2 A different application gets the handle value from a record from a database query  based on other information that is available.

EG : select paid from report.db where fieldx=‘abc’  and fieldy =‘def’

Now this ‘different’ Autoitn app has the window handle so that it can interact with the correct INSTANCE of the app that has multiple instances open. With the correct handle value, there is no way that the wrong instance is selected.

The window handle for the correct app is obtained with the standard Autoit “WinGetHandle” during the time that  AutoiIt app is automating the creation of a new instance of the app that has multiple instances.

When a new instance is created, a new xml file is created and an associated record is added to the database.

I can change the process so that I leave the each new instance open and just close the current report. I then can update the xml file, update the correct record in the database and then re-open the report. I just have re-invent some new processes. 

If I can do one of the following it would make things easy:

1. Assing a window handle to an application that I am about to open

2. Assume that if a specific application is closed and then reopened before any Other app is opened , the handle will be the same.

3. “Look ahead” and know what the next handle will be for the next application opened.

 

 

 

[RTFC]

The answer to all three hypotheticals is: "No, you can't." The OS kernel is the only entity allowed to assign (window) handles, which are basically (intentionally) obfuscated pointers in a dynamic master table. Letting users tinker with this is a terrible idea.

I would suggest you rethink your entire approach, using IPC instead, i.e.,

1. AutoIt app1 (HG?) creates multiple windows and associates each retrieved handle with other data relevant for identification later on; it does not close any of these instances.
2. for each window/task, app1 starts AutoIt app2 and parses it the relevant data including the handle (for example as command line parameters, a MailSlot message, ini-file, whatever...), to act on a selected window opened by app1 (and still running),

[Danp2]

6 hours ago, AutoitMike said:

The window handle for the correct app is obtained with the standard Autoit “WinGetHandle” during the time that  AutoiIt app is automating the creation of a new instance of the app that has multiple instances.

Why can't you launch the 2nd AutoIt script here and pass the handle as a parameter?

Quote

When a new instance is created, a new xml file is created and an associated record is added to the database.

By which app? The HG app?

Quote

I then can update the xml file, update the correct record in the database and then re-open the report. I just have re-invent some new processes.

It still isn't clear why you would be modifying these values.

Quote

If I can do one of the following it would make things easy:

None of these are valid / possible AFAIK.

[OJBakker]

I have read this thread multiple times, looked deep into my foggy crystal ball, and made some (un)educated guesses.
This is my summary of the problem:

You get an email with an attachment with some info.
This email is the trigger to start a home inspection 'action'.
You have made an AutoIt script that uses info from this email to start the HG program with this info ('email-script').
Now the HG program is running.
This program runs and will create an xml file with the name report.hg5 and add/update a SQLlite database with some info.
Where these file are located and when these are written/updated is unclear but this seems to be done/finished only when the program is stopped.
These files/records have a field with the name 'status' that can be used to store additional info.

There can be multiple emails so multiple instances of the HG program will be  started, each one triggered by a specific email-message.

Later you get sets of pictures you have to upload to the running HG programs and you want to automate this process with an other AutoIt script ('pictures-script').
The problem is you have to make sure you are uploading the pictures to the correct instance of the HG program.
 
You decided to use/abuse the 'status' field in your attempts to solve this problem.
You do this by storing the window-handle of the just started HG program into the 'status' field of the HG program after you have started this program ('email-script').
The window handle and process-id of the HG program are useless as soon as the HG program is stopped because these are temporary by definition.
You can restart a program and it will get a process-id and window-handle but these are newly created and will never have the same values as before the restart. 

How do you as a person know which pictures are to be uploaded to which running instance of the HG program?
How do you get the pictures?, also by email?
The 'email-script' has the info you need in the 'pictures-script' and both are fully under your control.
So this problem must be solvable. You just need to find the most suitable item to use.

Maybe the message-id of the email that starts the inspection 'action' can be used in the 'status' field?
Or if there is some sort of unique inspection-id created by the HG program,  you can use that to connect the pictures to the corresponding HG program instance.

Is it possible to start the HG program and load an existing inspection 'action'?
If this is possible you could change your scripts so the 'email-script' just creates the 'action' and then closes the HG program
and later the 'pictures-script' restarts the HG program with the correct inspection 'action' and uploads the pictures.