I don't know how an application would even detect the order in which you delete keys from the Win32 registry. It sounds down-right foolish for a application to require something so bizarre as that. But you give us virtually zero details on this so it is hard to say much more than that about it.
Make the fix to TieRegistry.pm that Thelonius suggested then try:
I have no idea what that would accomplish, but with such bizarre requirements, it might just do what you want. All that I know about RegFlushKey() is included in the module documentation ("it is almost never necessary to use it").$OpenKey->Flush( 1 );
It sounds like your (unspecified) application is using some knowledge of specific aspects of how the registry editor does things when it deletes your (unspecified) keys. Perhaps you should try to emulate it. When you delete a key, it has to refresh the display and so it probably re-reads the parent key. An application could certainly register that it wanted to be notified when a key is read, so perhaps that action is what is required.
Rather than keep restating that you need to delete the keys in a certain order (you are already doing that, and have been from the beginning, even if you don't close the key with undef -- key delete operations are not cached or otherwise delayed), perhaps you should try to get more information from the application provider to figure out exactly what they mean or how they go about detecting this or why they have such a strange requirement. Any of those items might give you more information on what you are supposed to be emulating.
- tyeIn reply to Re^3: TieRegistry - How does Flush( $bFlush ) work? (undefined)
by tye
in thread TieRegistry - How does Flush( $bFlush ) work?
by trout16
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |