Set Source/Focus not working properly?

Help & Support
4

@Nudel
I understand this may have been one of the intended reasons for using Lister Styles, which will definitely get you the folders you want open in the lister. However, one utilization of Lister Styles is to just govern which elements appear in a lister, without saving folder paths in the style. If a system admin needs to create 20 or so styles just to govern Synchronize operations, the Styles Tab quickly gets cluttered with their Synchronize styles mixed in with the Element governing styles. It starts to become unfeasible for users like system administrators and web developers to set up a Lister Style for every Synchronization operation they need to perform.

Configuring a single Synchronize Style, and several toolbar buttons to load the folders (which could be added to menu of such buttons) makes a lot more sense. However, all the commands that should help in this endeavor have some sort of issue attached that prevents this.

@darkuni
It bugs me too (as in there is a bug in here). I can reproduce all of these same issues. A significant point here is that the commands: Set STATE= and Go OPENINDUAL OPENINSOURCE OPENINDEST OPENINLEFT OPENINRIGHT DUALPATH= produce inconsistent results when used from within a dual lister.

In fact, these issues have been on my list to test more thoroughly, write up, and submit detailed test cases and results to GPSoftware for some time now. I have just recently filed some of the related issue reports, but I have more to go through. These issues are one of the major reasons I submitted the Sync Pairs feature request.

Please click on the link above an read through the suggestions I have already submitted to GPSoftware. Also, please add your thoughts to that thread as well. I think you'll find that you and I are on the exact same page. However, if you see anything I've missed, please add it to the discussion in that thread, or at least acknowledge if those ideas make sense or not. I've tried to inspire some discussion there, but haven't had any takers (or detractors), which is particularly disappointing.

5

Well, guess what? Style doesn't work either! It holds BOTH lister states fine, but does NOT turn on Flatmode as it should.

Check out the screen shot. I JUST hit the STYLE I created. You can see that the proper location IS being loaded in the lister - it is even sorting right. But it is NOT flatfile'ing as it is being instructed.

Thoughts?

6

[quote="kenalcock"]If a system admin needs to create 20 or so styles just to govern Synchronize operations, the Styles Tab quickly gets cluttered with their Synchronize styles mixed in with the Element governing styles. It starts to become unfeasible for users like system administrators and web developers to set up a Lister Style for every Synchronization operation they need to perform.

Configuring a single Synchronize Style, and several toolbar buttons to load the folders (which could be added to menu of such buttons) makes a lot more sense. However, all the commands that should help in this endeavor have some sort of issue attached that prevents this.[/quote]

Why not just create a menu of Lister Styles instead of TABS then?

Prefs STYLE="name of style"

7

Something is definately awry here.

I created a STYLE as outlined above. I created a button for it as outlined above.

The first time I use it, the TOP lister RETAINS the style it was PREVIOUSLY (despite it being told to change). If I select the style button AGAIN - it works as it is supposed to.

Here is a video: tinyurl.com/jr7sw

I put C drive in both listers. Then hit my style change button. The PATHS load right, but the TOP lister (despite the style SPECIFICALLY saying DETAILS) doesn't change. I then call the style AGAIN - and it "works".

Thoughts?

8

Using a Layout seems to work for me, although I haven't tested it a lot.

9

It's been a long day for me and I'm only quickly scanning this thread so I'm way out of touch with the discussion. But in regards to flat view mode in general, I seem to recall Jon saying once that by design, putting a lister into flat view is a dynamic change, one that cannot be reliably saved in a layout, style, etc.

10

If that is the case, wouldn't the option in the Lister Style dialog be pretty much useless?

11

[quote]Why not just create a menu of Lister Styles instead of TABS then?

Prefs STYLE="name of style"[/quote]
Certainly the command above provides a button that successfully applies a lister style which will successfully list two folder paths in the desired lister panes.

However, using Lister Styles approach does not address issues raised earlier. Regardless how Lister Styles are applied, using them forces the user to create multiple Styles simply for the purpose of storing different pairs of folders to synchronize between (Let's call these "Sync Styles"). Each Sync Style is essentially an identical combination of lister elements--only the folders listed in each pane are different. Sync Styles cannot store the actual parameters of the Synchronize operation, thus they offer little value to someone who has several routine Synchronize operations to perform periodically. The only benefit is they accurately store and list which folder paths open in which lister panes. The user still must manually configure the parameters of each Sync operation, because that utility panel always stores the parameters of the previous sync operation (which may not apply to the next sync operation). To me this approach is very cumbersome and inefficient.

Also, I don't know how most people utilize Lister Styles. But personally, I never store folder paths in them. I use Lister Styles to quickly reconfigure which lister elements the current lister uses: folder tree, viewer pane, single pane, dual (horizontal/vertical) pane, et cetera. In other words, I use Lister Styles to actually style the lister. Let's call this utilization "Element Styles" since it only governs the elements of a lister, not the folders displayed in the lister. I use the Styles - Tab on the Tabbar to display my collection of Element Styles allowing me to, with a single mouse-click, reconfigure the current lister from a Element Style more useful for say managing files, to one more suitable for say viewing digital images or .pdf files.

If I started using Lister Styles for the purposes of storing synchronize folders pairs, the Style Tab will soon become cluttered with Sync Styles. I currently use about 10 Element Styles, and I require about 20 different Synchronize Folder pairs now, and that number is only growing. The Sync Styles will be mixed in and among the Element Styles, and I'm not aware of any way to filter which styles appear in the Style Tab. So eventually this renders the Styles - Tab useless to me for the purpose of governing which lister elements are in use. I do not want to lose this flexibility. I'm pretty much static on my top ten Element Styles, and they fit on the tabbar nicely. The command quoted above does nothing to help keep the Styles - Tab usable. It is using Lister Styles just to navigate to a pairs of folders that I am opposed to, not how to apply a single Lister Style from the list of them. I should be able to configure a single Lister Style that is perfectly suited for Synchronizing and use it like a reusable object, applying different folder paths to its panes using Go commands.

One of the big things holding me (and darkuni) back right now, is that the Go and Set State commands have issues working from within a dual lister, depending on which pane has focus and which pane is the Source or Destination. This is a real issue. I'm still developing test cases and a set of steps that consistently reproduce results (though it has not been very consistent). When I have more information such that I can make an intelligent observation and suggestion, I will submit an issue report.

For navigating to and between folders, Opus provides a host of options: [ul][li] The Drives toolbar[/li]
[li] The Folder Tree[/li]
[li] Hot Paths[/li]
[li] Favorites and Smart Favorites[/li]
[li] The Go menu[/li]
[li] The Go raw command[/li][/ul]With all the above options for folder navigation, I shouldn't have to rely on Lister Styles to navigate to a couple of folder paths. If I have high-traffic areas, Smart Favorites will help me find them and Favorites will help me dictate them before Smart Favorites finds them. If I want VIP access to a location, I create a button in my GO menu, or even another menu. For example, I created a System menu which takes me to all the system administration hotspots on the system, or relative to the current user (essential if you are a system admin).

If I need to perform a specific operation at a particular location (or between two of them), I want to create a custom a toolbar button to handle the job because it will save a lot of time and reduce human mistakes by automating the process as much as possible. I should be able to apply an Element Style, Go to a couple folders, Select some files, and Copy files in an automated manner, and ideally in one customized toolbar button. Thus raw command support is essential for automation, and ideally Sync Pairs is given serious consideration. The Sync Pairs request I submitted was to more less completely automate a synchronization between two explicit paths.

12

Using a Layout to turn on Flat View mode works fine, as far as I can tell. I didn't try with Styles.

You can navigate to a pair of directories with a single Go-command involving neither Layouts nor Styles. What's complicating this example is that as well as that navigation we want to do other things like set the display mode and sort order and, most importantly, turn on flat-view. That's what Styles and Layouts are for, although the Go command has arguments which let you set some of those things (e.g. display mode) as part of the nagivation.

If using Styles/Layouts for this kind of thing gets in the way of using them for other things, because those Styles/Layouts are then included in lists/menus/tabs, then I think the solution is to be able to filter which Styles/Layouts are shown.

A simple but probably adequate solution would be to give each Style/Layout a "Hidden" flag which means it is available for use via commands but won't be included in lists. Just like the special Dupe and Sync layouts have already, but controlled by the user.

If you still want to use the command approach and not use Styles/Layouts then shout and I'll see if I can work out a command sequence that works reliably to navigate to a slow-loading folder and then turn on flat-view without the asynchronous commands causing a race condition.

13

It does not work consistently, when a folder path is specified inside of the Style. It seems to work well as an Element Style, where no folder path is saved. I'm seeing some really bizarre results here.

Now I am no we here near done with my testing on this. But I have seen a single Go command with two paths work, and I have seen it not work. At the moment, I just can't isolate what sequence of events makes it not work. I haven't reported this as an issue yet, because I need more testing and more proof.

I agree this complicates things.

It has been my impression that a multi-raw command toolbar button could apply a style then navigate to the folders of choice. This has proved troublesome though.

[quote]If using Styles/Layouts for this kind of thing gets in the way of using them for other things, because those Styles/Layouts are then included in lists/menus/tabs, then I think the solution is to be able to filter which Styles/Layouts are shown.

A simple but probably adequate solution would be to give each Style/Layout a "Hidden" flag which means it is available for use via commands but won't be included in lists. Just like the special Dupe and Sync layouts have already, but controlled by the user.[/quote]
I agree this would help a great deal. However, the other legitimate issues that have been raised (Flat View not working in styles, raw commands not working consistently, et cetera) still need to be addressed, if in fact they can be shown to be legitimate issues.

I was thinking of creating a script using dopusrt.exe to use as a User command. I've done this with other operations. I just haven't gotten around to it yet for this application, because I spend most of my "Opus Time" these days testing and logging issues.

14

I think it would be better to navigate and then apply the style, else you're turning on flat-view for the current directory before navigating away from it, which could waste time or cause things to fail (because the flat-view scan is still happening).

15

I think it would be better to navigate and then apply the style, else you're turning on flat-view for the current directory before navigating away from it, which could waste time or cause things to fail (because the flat-view scan is still happening).[/quote]
Good point. Then the act of listing the two folder paths must also ensure the lister is switched to dual-panes. This has been what has proved problematic. I wasn't even using Flat View (but darkuni is).

Actually, doesn't just running a Synchronize operation automatically display the results in Flat View? Thus, there is no reason to actually force Flat View in a style intended for Synchronization. But the technique still might be interesting for other purposes.

16

[b]Go PATH C:\ DUALPATH D:[/b] should reliably switch to dual panes with the two paths.

17

[quote]JohnZeman wrote:
It's been a long day for me and I'm only quickly scanning this thread so I'm way out of touch with the discussion. But in regards to flat view mode in general, I seem to recall Jon saying once that by design, putting a lister into flat view is a dynamic change, one that cannot be reliably saved in a layout, style, etc.[/quote]

You're right Ken, it's been a long grueling week for me at my day job and the strain I've been under there is starting to show in my posts here. :confused:

In my half asleep mind last night I had mixed up flat view with navlock. It was navlock that Jon once said is dynamic, sorry for the confusion. TGIF!

18

In my case, I'm a web applications developer that needs to promote code from DEV to STAGE(test) at short intervals; daily, every other day, maybe after a weekend.

PURE syncronization may not be effective for me. Sometimes I need to release changes selectively. I don't want to promote .vcc files over. There are a number of conditions that can occur where really, all I want, are DEV and TEST's folders up, DEV's listing flattened with the most recent files on top so I can make some educated decisions.

I believe the inconsistancies are dealing with the program simply running TOO FAST to match the relatively SLOW file system across the network.

I'm guessing what we REALLY need is a means to set scripts to run "single threaded" (for lack of a better term). Which means, SET FOCUS, if it is the SECOND line of a script, DOESN'T RUN until the first line (in our case, a GO command). I don't even know if that is possible. But it SHOULD make things work right.

Sadly, I'm forced to hit my newly made button TWICE to make it work - but that's ok for now.

19

If you want to try the layout approach the command to load a saved layout is

Prefs LAYOUT="FDR Backup"

(replacing the last part with your layout name).

20

I don't know how feasible this is. But I completely agree with the concept. There have been so many times where I've tried to script a number of Opus commands inside one button, and there seems to be no way to get them to work in a queue where each command waits for the previous one to fully complete.

I have tried using sync: in conjunction with dopusrt.exe to launch commands, but I have always had varying degrees of success.

I think Opus needs a raw command equivalent of the Windows: Start /Wait command to wrap around all raw commands in a button in order to force each to wait for the previous one to complete before starting. Again though, I do not know if this is feasible from a coding perspective.

I do know that many custom buttons would benefit from such a construct, and it would help immensely in automating user tasks.

21

dopusrt.exe itself will finish once the command has been dispatched; dopusrt.exe doesn't wait for the command to complete (the same as running the command internally), so syncing on dopusrt.exe doesn't have any benefit in this case.

In general, the sync: stuff is only useful to ensure that further internal commands are not dispatched before external commands have completed.

22

[quote="darkuni"]Go \\DEV-UNCPATH OPENINLEFT Go \\TEST-UNCPATH OPENINRIGHT Set Flatview=grouped Set SORTBY=accessed SORTREVERSE=On

Now this ACTUALLY WORKS - provided that you put focus on the TOP (left) lister BEFORE you hit the button. If the BOTTOM lister has focus before hitting the button, the BOTTOM lister gets the flatview and sortby.

Ok, we should be able to fix this, right? Before calling the display commands we add ...

Go \\DEV-UNCPATH OPENINLEFT Go \\TEST-UNCPATH OPENINRIGHT SET FOCUS=Left <- new Line Set Flatview=grouped Set SORTBY=accessed SORTREVERSE=On

Right - now, no matter WHAT lister you have 'in focus', the LEFT one should ALWAYS get the flatview/sortby.

Unfortunately, this isn't the case. And I can't tell you why it doesn't work.

I have a feeling it has to do with "what lister populates first" ... the DEV server here is slower than the TEST server ... so while the DEV lister is loading, TEST is already done (even before the flat view). Other than that, I can make no sense of this anomaly.[/quote]
@darkuni
Okay, I think I have finally stumbled on a solid workaround to the issue highlighted above. It works okay for me on a non-networked system (I'm out of my office for a couple of days). I'd like you to test it on your network and see if it works.

Set FOCUS=Left SOURCE=Left Go OPENINLEFT "<new source path>" DUALPATH "<new destination path>" Set FLATVIEW=grouped SORTBY=accessed SORTREVERSE=On
The key is to ensure that the left lister pane is both the source and has focus before loading the new paths. In a single lister the only lister pane is the left lister pane. Then with one Go command load both paths. Also one final Set command will set all of your options.

23

Correction the final set command will not set all of your options. I'm still working on this.