I have no idea what $bFlush is, what it means by "specified", what it means by "and a true value", or what RegFlushKey() is and why it would be necessary.

RegFlushKey is a Windows API subroutine. See regflushkey.

This doesn't give me an error, but it doesn't work:

$Registry->Flush();
[download]

So, I tried this:
$Registry->Flush( $bFlush );
and I get this error:
Usage: $Key->Flush( $bFlush );

    my( $flush )= @_;
    @_  and  croak "Usage:  \$key->Flush( \$bFlush );";
[download]

    my( $flush )= shift(@_(;
    @_  and  croak "Usage:  \$key->Flush( \$bFlush );";
[download]

Let me rephrase this: "Both keys are being deleted, but the result is similar to what would happen if I deleted the second key first and the first key second."

Both the first key and the second key are being deleted. However, the undesireable result (to keep this short) of the code is exactly what would happen if I manually deleted the second key first and the first key second.

I still don't understand. Are you talking about the final result in the registry or something that happens between the two deletions?

As far as I'm aware, the order of deletions of keys shouldn't make any difference for what the registry looks like in the end.

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.

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