Re: Re: TieRegistry - How does Flush( $bFlush ) work?

Thelonius,

The first key must be deleted before the second key. It's a requirement for a custom app I have acquired that will be run after deleting these keys. If I could, I would let you try out this app. If I manually delete the first key first and the second key second, the app will work correctly. If I manually delete second key first and the first key second, the app will not work correctly unless I reboot after deleting the keys (I am trying to avoid rebooting). I can see that the app creates the wrong registry keys if I delete the first and second registry keys in the wrong order, or if I delete these keys with TieRegistry (in any order).

When any registry key is deleted manually, something happens with the system afterwards that does not happen when you delete a registry key with TieRegistry. Perhaps "Lazy flushing" occurs? I don't know.

Maybe if I use Flush correctly after deleting the first key this will work, but I still haven't figured it out. What does this mean: "the optional $bFlush is specified and a true value"? I know what a true value is, but I can't figure out what this Flush subroutine is expecting.
Is this the extent of what it means by specifying $bFlush:
$Registry->Flush( $bFlush );
Does it want this exact variable $bFlush to be passed to the Flush subroutine? Does $bFlush already have a value, or do I have to set it equal to something? The "true value"?

Thanks for your help. Maybe I'm closer than I think, or maybe I need to try a different approach.

Comment on Re: Re: TieRegistry - How does Flush( $bFlush ) work? Download Code

Replies are listed 'Best First'.
Re^3: TieRegistry - How does Flush( $bFlush ) work? (undefined) by tye (Sage) on Aug 14, 2003 at 21:28 UTC
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: `$OpenKey->Flush( 1 );` [download] 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"). 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. - tye	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: TieRegistry - How does Flush( $bFlush ) work? (undefined)
by tye (Sage) on Aug 14, 2003 at 21:28 UTC

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:

    $OpenKey->Flush( 1 );
[download]

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.

tye

[reply]
[d/l]