PureBasic Forums - English

My app needs to know which windows are visible at any given time, for later
use. That's easy: just do a loop and get all the handles. But, if my app crashes,
it loses the list. I don't really want to store the list as a disk file because of
speed reasons, and the fact that it might be running on read-only media,
and I don't want to store them in the PC's "Temp" folder either.

So, I thought perhaps I could use the SetProp API to mark each window with
a flag like "Monitored by MyApp" or something, so that if my app crashes, and
gets restarted, it can parse all windows again, and GetProp should let me see
which ones were previously being watched before the crash. Capiche?

But, from my testing, SetProp and GetProp can only be used by the app that
sets them. So on my app's re-launch, using GetProp fails as the new instance
of the app didn't do the SetProp on them (the crashed instance did).

How would you guys approach this problem, without using file access? Also,
I don't want to change the window captions, as they can be changed by the
apps themselves at any time.

Maybe you could use a global atom table. Data is still there after your program ends unless you explicitly free it.

But if your app crashed, would you still want to monitor the same windows? Might the focus of the windows have changed? Or am I (likely) misunderstanding the question?

cheers

I have no idea what a global atom table is. Can you give a short example?
Like, create an array of 3 numbers (which will be the window handles), store
them in this table, exit the app, and restart another app that can read those
3 handles. That's the goal.

@rsts: Yes, when my app restarts, I want it to know which window handles
it stored when it did the scan, before it crashed. Focus doesn't matter. For
example, if the scan noticed that Calc and Notepad were running, and my
app crashed and then restarted, and Notepad was closed too, then when
my app restarts it will say "ah, Calc with a handle of X is still there, but
Notepad with a handle of Y is gone".

BTW, the main reason I don't want to use a file, is if the PC restarts. Upon
a restart, my app would read the file and all the handles would be irrelevant.
But if the app just quits and restarts, the handles would still be relevant.

Gotcha.

You could keep an indicator in the file as to whether or not your app completed successfully and act accordingly.

No idea about global atom table either

cheers

Using a file is not an option, as the app runs 24/7 and doesn't normally quit.
Files are slow too (think USB or floppy writes). A global atom table sounds
like what I need, but I have no idea what they are or where to start.

PB, maybe this will help? Or look up GlobalAddAtom on msdn. Never used global atoms myself so I don't know whether they'll help or not...

Thanks eesau, but I don't think that'll work. You need to know the name of
the atom to retrieve it later, and since I want to store window handles...

Ah, you're right, doesn't seem like the best solution then.

The global atom table is the wrong place for this.

Atoms are used to map strings to unique numbers so they can be used more easily in interprocess communication. They are intended to map names for data formats and things like that, they are not intended for mass data storage.

Honestly i don't understand your fear of files. Todays filesystems do massive caching, so you probably won't notice any slowdown at all. Especially if your file is small and you keep it open all the time, the odds are that the data will not even end up on disk at all. Of course you shouldn't write the file to a floppy. Use the temp directory for this. This is exactly what this directory is meant to be used for.

As for the restart issue, you just have to detect this case and act accordingly. Use the system uptime for example (there was a thread about this recently)

PB wrote:My app needs to know which windows are visible at any given time, for later
use. That's easy: just do a loop and get all the handles.

You don't use GetWindow(), do you?

EnumWindows() help wrote:This function is more reliable than calling the GetWindow function in a loop. An application that calls GetWindow to perform this task risks being caught in an infinite loop or referencing a handle to a window that has been destroyed.