^ Bug? Intermittent Branch View not Removing

[Zardoz2293]

I'm encountering intermittent non-removal of the Branch View in script code. I haven't figured out how to reproduce it consistently.

Code: Select all

$Path =  "<curpath>";
goto "$Path ? /flat";
$List = folderreport("files", "r", "$Path", "r", ,"|");

...

goto "$Path";

It's been occurring ever since I started using the Branch View. In the address bar it says: "C:\WhateverFolder\ ? /:flat", but the value for $Path is "C:\WhateverFolder";

What are your thoughts?

[Zardoz2293]

There are at least four undesirable 'random' events that occur with the scripting code below. The script has two methods to be assigned a keyboard command each. One for archiving (script-label: "archive") and one for unarchiving (script-label: "unarchive") as set of folders. All folders from the selected "parent" folder and all the parent's children folders will be renamed and the hidden attribute set or removed :

• Eventually either archiving or unarchiving a set of folders (typically at least two levels deep) will result at the end of processing with the Branch View enabled, but the Branch View should be explicitly removed. It's hit or miss as you can archive/unarchive back-in-forth and it works almost all of the time, then without reason on the same folder set the Branch View will be still "on" at the end of processing (this shouldn't happen -- see code).
• Directly related to the above item: Assert will not report if the Branch View is going to be active (see code). I'm assuming the assert works correctly and there is something going on behind Branch View and hence why assert isn't reporting.
• Most of the time on a two folder level deep tree or more, nodes condensed/expanded, the archive/unarchive will result in expanding/contracting the node from the parent level. The renaming of the folder shouldn't change how the nodes are displayed in the Tree View other than renaming the specific node.
• Tab Folders will spontaneously get created on very deep levels of folders. You can archive/unarchive the same folder set again and again and nothing will happen. Then it starts for no apparent reason, creating dozens of tab folders and more . Can be hard to recreate.

Folder Structure Set:

Code: Select all

Parent           <DIR>
   Child         <DIR>
   ...
   Child         <DIR>
      ...
      Child      <DIR>
         ...

Simplified Archive/Unarchive Script:

Code: Select all

// Version 2.0 / 2012-02-14
// Copyright 2012 - Zardoz2293
//
// 1) User | Manage Commands... --> Label: archive
// 2) User | Manage Commands... --> Label: unarchive
	
"_body"
	// Declare
	$c_Folder          = 2;              // Assumed to be a Folder.
	$c_Pipe            = "|";
	$c_Action          = "{A} ";
	$c_status_progress = "progress";
	$c_status_alert    = "alert";
	$c_status_ready    = "ready";
	$c_color_red       = "FF0000";
	$c_count           = "count";	
	$c_BranchView      = "? /:flat";
	$c_NotFound        = (-1);
	$c_attrModeSet     = 1;
	$c_attrModeRemove  = 4;

	global $g_attrMode;	
	

	status( "Activity...", , $c_status_progress );	
	if ($g_attrMode != 0) { 
		// Mode: Deprecate.
		$g_attrMode = $c_attrModeSet;		// Set
	} else {
		// Mode: Undeprecate.
		$g_attrMode = $c_attrModeRemove;	// Remove
	}	
	
	$TypeFind = "<curpath>";

	$CountFolder = 0;

	goto "$TypeFind" . "$c_BranchView";

	// Process Each File.
	$List = folderreport("files", "r", "$TypeFind", "r", , $c_Pipe);

	// Add selected Folder to the list for processing.
	if (exists( $TypeFind ) != $c_Folder) {
		$Folder = "$TypeFind";
	} else {
		// Currently selected a Folder in the TreeView or ListView.
		$List = folderreport("dirs", "r", "$TypeFind", "r", , $c_Pipe);
		if ($List != "") {
			$List = $TypeFind . $c_Pipe . $List;
		} else {
			$List = $TypeFind;
		}

		// Process Each Folder.
		$ErrorFolder = 0;
		foreach ( $Folder, $List, $c_Pipe, "r" ) {
			if (exists( $Folder ) != $c_Folder) {
				status( "Internal failure. The Object '" . $Folder . "' is reporting it isn't a Folder.", $c_color_red, $c_status_alert );
				goto "$TypeFind"; //Restore original starting folder.
				end( "Error Encountered. Processing Stopped." );
			} else {
				// Folder: Prefix "{A}".
				$FindExisting = gettoken( $Folder, -1, "\" );
			
				if (substr( $FindExisting, , strlen( $c_Action ) ) != $c_Action ) {
					// Apply Prefix "{A}".
					$Folder = renameitem( $c_Action . "*", $Folder );
					if ($Folder == "") {
						$ErrorFolder++;
						status( "Action: " . $CountFolder . " Folder" . (($CountFolder != 1) ? "s, " : ", ") . "Rename Errors=" . $ErrorFolder, , $c_status_progress );
					}
				} elseif ($g_attrMode == $c_attrModeRemove) {
					// Undeprecate only if Attribute Mode is Remove.
					$Folder = renameitem( substr( $FindExisting, strlen( $c_Action )  ), $Folder );	
					if ($Folder == "") {
						$ErrorFolder++;
						status( "Action: " . $CountFolder . " Folder" . (($CountFolder != 1) ? "s, " : ", ") . "Rename Errors=" . $ErrorFolder, , $c_status_progress );
					}					
				}				
				attrstamp( "h", $g_attrMode, $Folder );
				$CountFolder++;
				status( "Action: " . $CountFolder . " Folder" . (($CountFolder != 1) ? "s, " : ", ") . "Rename Errors=" . $ErrorFolder, , $c_status_progress );
			}
		}
	}	
	
	// Finished.
	assert strpos( $Folder, $c_BranchView ) == $c_NotFound, "Branch View NOT removed: $Folder", 1;
	goto "$Folder"; //Restore original starting folder.	
	
	if ($ErrorFolder > 0) {
		$Status = $c_status_alert;
	} else {
		$Status = $c_status_ready;
	}
	status( "Action: " . $CountFolder . " Folder" . (($CountFolder != 1) ? "s, " : ", ") . "Rename Errors=" . $ErrorFolder, , $Status );	
	releaseglobals;

	
	
"Unarchive : unarchive"
	// Declare
	global $g_attrMode;
	
	$g_attrMode = 0; // Unarchive.
	sub "_body";

	
	
"Archive : archive"
	// Declare
	global $g_attrMode;
	
	$g_attrMode = 1; // Archive.
	sub "_body"	
	
// END: Main

What are your thoughts?

[Twisten]

I've faced a somewhat similar situation, and this question comes to mind, why use branch view at all ?
You're already using folderreport to get a list of files with absolute paths and doing it recursively, using goto can only lead to complications if you rely on the result an accidental click in the GUI can screw up you script.

I realize this doesn't address what unexpected behavior you noticed with branch view but I hope it'll help with your script, I haven't used branch view personally (especially in scripts) so I can't comment on that part.

[Zardoz2293]

I've faced a somewhat similar situation, and this question comes to mind, why use branch view at all ?
You're already using folderreport to get a list of files with absolute paths and doing it recursively, using goto can only lead to complications if you rely on the result an accidental click in the GUI can screw up you script.

It is my understanding that folderreport, at least, before BV existed didn't order the folders and files in a very specific order that is needed. For me, the ordering of the folders and files is a technique I've used and needed in systems work for 20+ years. Therefore, why it wasn't/isn't in folderreport? It seems BV was given capability beyond what folderreport can/will do. I don't like how BV changes the screen, from my perspective, nothing the end-user could do during an executing script should be capable of messed it up by introducing an unwanted branch in the execution path. I don't do any keyboard or mouse activity during the script processing, so that's not a top concern, although it is another issue with using BV. Frankly, I'm using BV as I find string processing for folders and files take a lot of overhead, and is error prone. I really don't want to do any kind of string processing within script, rather call script commands to perform those services.

I realize this doesn't address what unexpected behavior you noticed with branch view but I hope it'll help with your script, I haven't used branch view personally (especially in scripts) so I can't comment on that part.

It appears to be random effect of BV staying in BV mode at the end of scripting sometimes. You can perform the script on the same folder structure over and over again, and then, one time it stuck in BV mode. I'm not sure I'm willing to modify the script to perform all of the string processing myself. I can get more mileage by writing a .NET app that performs those services and some other things I need as well in about the same time to do the rewrite.

[admin]

Not sure if this applies but BV is applied to any selected folder again. IOW, when a folder is selected in a BV list, then Toggle Branch View does NOT toggle it off for the current list, but open the selected folder in BV.

Does this explain what you experience?

[Zardoz2293]

Not sure if this applies but BV is applied to any selected folder again. IOW, when a folder is selected in a BV list, then Toggle Branch View does NOT toggle it off for the current list, but open the selected folder in BV.

Does this explain what you experience?

1. Your statement above: That is my understanding of BV's behavior.

2. Perform the following script should toggle off BV at the end of the code segment, yes?

Code: Select all

"main"
     goto "F:\XY.Test\? /:flat";
     goto "F:\XY.Test";

There's always the gotcha regarding paths that end in a folder and not a file as to how it should be formatted/terminated, i.e., "F:\XY.Test" v. "F:\XY.Test\". I've noticed some script commands (either through actual use or current help documentation) where the two variances are being used (in/out arg or ret). When I saw it, I saw a gremlin. I don't remember where this occurred, but know I've seen it and so did William Shatner.

Assign the script above to a UDC and execute the above code block and view the results. Keep performing the identical action, eventually you'll be blessed with "F:\XY.Test\? /:flat" at the end of the script and wonder how. Further, there seems to be something else, either BV or UDC -- take your UDC keyboard command for the above script and hold down that shortcut, don't release and watch what happens. I'm off to lunch with Will.

Update:
I'm now starting to seriously think this bug and a couple of other very odd bugs I've posted here, which are still outstanding, are all related. I'm getting a strong feeling the UDC is causing the failure. It's the underlined and bold statement above. I don't think the UDC prevents executing script reentry and from my perspective an executing script should not be allowed to be executed again until it's finished, when called by the UDC. Is that occurring? Is this something we can resolve, assuming script reentry is actually allowed and occurring? If so seems like a very quick fix to validate. Thanks!

[admin]

OK, I will prevent script reentry from UDC.

BTW, did you use tweak ScriptRecursionWarningOff = 1? Otherwise you should have seen a warning instead of the phenomena...

[Zardoz2293]

OK, I will prevent script reentry from UDC.

BTW, did you use tweak ScriptRecursionWarningOff = 1? Otherwise you should have seen a warning instead of the phenomena...

1. What I was getting with the UDC when the keyboard combination was continuously pressed: XY would get semi-locked up and pressing the ESC key was needed to get it out of whatever funk it was in (this was an exclusive XY thing as it doesn't happen with anything else in my system).

2. Never saw any warning dialog. Therefore it must have never entered recursively.

XYplorer.ini

Code: Select all

ScriptRecursionWarningOff=0

3. The BV now stays on at the end of processing more consistently.

4. My script is now broken with the other BV changes.

5. If it wasn't a recursion issue with UDC and BV staying on, then this and my two other scripting items I've reported are not addressed.

[admin]

I cannot reproduce it here. But I could get some issues (but not yours) before I prevented reentry.

[Zardoz2293]

OK, I will prevent script reentry from UDC.

BTW, did you use tweak ScriptRecursionWarningOff = 1? Otherwise you should have seen a warning instead of the phenomena...

1. What I was getting with the UDC when the keyboard combination was continuously pressed: XY would get semi-locked up and pressing the ESC key was needed to get it out of whatever funk it was in (this was an exclusive XY thing as it doesn't happen with anything else in my system).

2. Never saw any warning dialog. Therefore it must have never entered recursively.

XYplorer.ini

Code: Select all

ScriptRecursionWarningOff=0

3. The BV now stays on at the end of processing more consistently.

4. My script is now broken with the other BV changes.

5. If it wasn't a recursion issue with UDC and BV staying on, then this and my two other scripting items I've reported are not addressed.

I cannot reproduce it here. But I could get some issues (but not yours) before I prevented reentry.

Don, interesting, I consistently get the same kind of issues. I'm not concerned as I've taken another path regarding BV and eliminated it from my scripts. Everything now works as expected. Better to spend time on other subjects until or if others experience the phenomena. When you added the reverse foreach that added a significant dimension (enhancement) to scripting from my perspective. Again, thanks!

• #1. Resolved = Build v10.80.0313 resolves this UDC concern.
• #2. Resolved = I'm not sure if I ever had any true recursion event. My settings were to display the warning. I haven't verified via a test as I'm assuming it works correctly.
• #3. Resolved = Build v10.80.0313 caused this anomaly to occur with greater frequency. I've eliminated BV from my scripts, so from my perspective this is irreverent.
• #4. Resolved = Removed BV from script.
• #5. Resolved = Removed BV; No longer performing sub-string activity http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=7588, perhaps an out of bound event; Suspect since the out of bound event doesn't occur the scripting dialog doesn't appear when it isn't active http://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=7604

I'm content.

Thanks everyone!