DllCallBackFree

[Melba23]

Good evening,

When I was working on the NoFocusLines UDF, I soon realised that before explicitly freeing the memory for the replacement WindowProc as the script exits you MUST delete all subclassed controls - or it is a crash for sure.

The current UDF version asks the user to add DllCallBackFree($hNoFocusLines_Proc) to their script, but this also requires the user to delete any subclassed controls themselves beforehand. Although this is not difficult (just delete all the GUIs created) it goes against the idea of a "user-friendly" UDF, so I began looking into how I might do this as a new function.

My first thought was to create a Dummy control to get the next ControlID in line and then run through all ControlIDs, deleting those which might have been subclassed ("Button" and "msctls_trackbar32" classes). However, I remembered that Autoit creates new ControlIDs in the first available space in the ControlID list, so it could well happen that the Dummy would not have the highest ControlID in use.

My next thought was to delete all the windows associated with the script process using WinList and WinGetProcess - no GUIs left now! But, as you all know, there are rather more windows associated a process than just the GUIs created within the script. Deleting ALL the windows seems to work when tested - but I am not knowledgeable enough about the inner workings of Windows to know if this would pose problems later on. For example, I found that anything with IME in its title appeared to be associated with Explorer - which gave me cause for concern.

So a few questions:

1. Although the Help file says freeing DLLCallBackRegister is a "good idea" - is is really necessary given that Autoit will do it for you? Testing shows no problems in ignoring the advice - the scripts exit normally without freeing the memory - but my previous coding experience suggests that clearing up your own creations is definitely the way to go. However, if the memory should be explicitly freed, the problem of deleting the subclassed controls raises its head.

2. So, assuming that the memory should be freed, is there a way of determining the highest in-use ControlID so any subclassed controls can be deleted before calling DllCallBackFree? I suppose you could loop from 1 to GUI_MAXCONTROLS, but 65532 passes seems a trifle excessive and takes some time!

3. Does the "delete all process associated windows" approach pose any problems to the stability of the system?

4. Or is there another way?

M23

P.S. Apologies in advance if I do not reply for a while - I am off on my hols and AutoIt definitely does not feature in my better half's plans!

[Valik]

Err, you could just restore the original window procedure before freeing the callback function.

The biggest problem I see is poor design. You're trying to put band-aids over the root cause of the problem. The root of the problem is simply you aren't properly managing your resource. You need to either store the original window procedure (and HWND) for every control you replace it for and then restore all those window procedures before freeing the callback function or you need to at least store the HWND and ensure all stored HWNDs are destroyed before you free the callback. You can't take a shortcut and skip the storage step.

[Melba23]

Valik,

Thank you for the quick reply. I apologise for my tardy response - but as I said, I was away on my holidays.

I quite take your point about managing the resource - I was hoping for a short-cut. I should have learnt by now - TANSTAAFL*!

Thanks again for your valuable time and advice.

M23

* TANSTAAFL - There Ain't No Such Thing As A Free Lunch (Robert A Heinlein - The Moon Is A Harsh Mistress)