Thanks for explaining this. However, I'll have to change the line anyway because the generated next/prev list doesn't work in Flatview.
@tbone: please change line 216 to this: data.Func.viewer.Command("open," & lastFile)
and change line 641 (or 637, I made a silent update where I deleted 4 lines. It's the line after "If arg.got_arg.viewer = True Then") to this: data.Func.viewer.Command("open," & file)
With these changes Tagger works correctly in flatview. Does it also work with your embedded command?
@jon
Thanks for confirming what I thought about that line. Can you also please tell us if the viewer.command() method runs things immediately or is there some additional step required (when passing a command object e.g.)? As mentioned, I think neither the naming nor the docs really suggest what happens here.
@kundal
I did! Now it works, thank you. o)
I tried skipping through the images with the viewer to see how the GUI behaves, it updates now once you give it focus again. I think that's how you described the new behaviour. We are getting closer with this I think. I had a look into the viewer events and since you already make use of them, you could add a timer to the GUI to update every half a second or so and let it sync with the image currently in the viewer. To prevent some kind of loop if you trigger "next" from the GUI, stop the timer, make the viewer change the image, restart the timer and only update the Tagger GUI whenever the item in the viewer is different from the one the Tagger GUI shows. What do you think? o)
Interesting and important "async" detail, thanks! Should really be added to the documentation! o) Still unsure about the case where a Command object will be passed. Is it comparable to invoking Run() on the command object directly and just source/target tabs and modifiers will be overriden?
@tbone:
The timer thing really works and would be easy to implement. The problem with this is that navigating with the viewer GUI currently doesn't work in FlatView. Another problem that occurs with the fix I provided for you is that images will not be automatically EXIF-rotated when opened with data.Func.viewer.Command("open," & file) and rotating them manually afterwards is a pain. I already reported both issues.
At the moment I'd like to stay with the Show command hoping that the Flatview issue will be fixed soon because I don't have a satisfying workaround for the rotate issue.
I still not understand why cmd.RunCommand("Show LISTSIBLINGS USEEXISTING " & """" & lastFile & """") throws an error for you because it's a simple Show command that should work even if the embedded Tagger command doesn't work correctly. abr also never reported a problem with this. What's the error message you get with this? I'm sure the "A method was called unexpectedly" came from the "data.Func.viewer.Command" part of the line and shouldn't appear with this version.
Would be nice if we could find out what's different for you. Sometimes it makes a difference when you change the order of arguments: cmd.RunCommand("Show " & """" & lastFile & """" & " USEEXISTING LISTSIBLINGS").
I also looked into the preferences settings for the viewer but can't think of a setting that could cause this.
Tagger now follows the selection in the viewer in realtime with a 300ms delay.
Tagger and it's parent viewer window are now working correctly with FlatView.
Some changes to avoid script errors when a bad button code with the argument VIEWER was used. For example if you use Tagger VIEWER from a button in a lister toolbar without starting Tagger "embedded" (enclosed by square brackets) or without starting a viewer instance first you'll no longer get a script error. If a viewer window exists Tagger will close that window and behave as if the argument VIEWER wasn't given.
Tested and it works! o) The Tagger GUI steals the focus from the viewer though, is that intentional?
That way you can only skip to next/prev via the viewer once, after that all input goes to the Tagger GUI.
I guess that can be quite handy for specific situations, for others it's not. Let me know what you think. o)
I'm glad Tagger no longer throws an error for you although it's still the same Show command. I only changed the order of arguments.
Basically it's intended that you navigate through files with the Tagger GUI and navigating with the Viewer is just an additional goodie.
The focus change is not intentional. The OnViewerEvent function creates a script variable that the timer event inside the dialog message loop detects to update the information. This forces the dialog to the foreground.
Unfortunately there's currently no good way to toggle the focus back to the viewer. The only VIEWERCMD argument I found that forces the focus to the viewer is Show VIEWERCMD=cmdbar which displays a FAYT-style command bar at the bottom of the viewer. A too dirty workaround to integrate it.
I really wish there would be an VIEWERCMD=foreground argument. => feature request
However, I'm quite happy with the focus change. It works great with mouse wheel or mouse click. For keyboard it's also fine if you want to watch one file after the other (how abr does) and immediately apply Tags or comment to them without having to toggle the focus manually somehow.
@tbone:
Are you aware that you can change the hotkeys for the next/prev buttons of the dialog in the script configuration? Currently they are alt++ / alt+NUM+ for next and alt+- /alt+NUM- for previous. I'll change the defaults with the next update so they can be pressed with one hand and it's more like the viewer hotkeys: alt+SPACE for next and ctrl+SPACE for previous. I think it doesn't make a big difference with these keys if you navigate with the viewer or with Tagger.
Are you sure? It looks like the line dlg.Control("editrange").value = i+1 is the cause for the focus to move back to the Tagger GUI.
Maybe there is a way to prevent this? Jon/Leo do you have any opinion on this? Is the focus pull back required for something else to work?
Yes, I think. I'm just thinking that trying to duplicate the viewer hotkeys to navigate from the Tagger GUI makes less sense for me, as I'd loose all the other viewer functionality like zoom/delete/reset/crop and so on. I'd prefer if the Tagger GUI sits silently above the viewer, updating itself without interfering while I seek through the images. If I like to move over to tag/edit some image, I'd give it focus and do so, but until then I expect it to be passive.
Other users probably think different about the focus thing and it might be perfect for them. o) I might not be the Tagger power user but this talking gives me some insight on the new scripting possibilities as well, so it's very welcome and interesting, whatever the fnial outcome is! o)
This line just initializes the update process. The event editchange in range input calls the function EditRange (and CheckSource) which calls the function UpdateDlg. The focus change seems to happen somewhere in UpdateDlg. I thought it's line 643 but it isn't. So applying changes to the dialog controls (name field, group control, listview, rating input) is most probably the reason for the focus change. I'll look into this. Would be nice to know how to toggle the focus from the viewer to the dialog because there's currently no documented way to do this with a single command.
Ups, sorry I should always look up the lines in the original uploaded version. It's line 775-778. I'll move that lines to other places where it won't steel the focus.
Which hotkeys (of 64) do you think should be also available from the Tagger GUI? It's easy to make the hotkeys of the viewer also working from Tagger because except of "Image convert" they're all VIEWERCMD commands. The hotkeys with modifier would be the same and the single character keys needed for text input could work with the modifier alt or ctrl.
Aha! Jetzt geht es! o)
Uhm, I meant, now it works as I like it, no more focus stealing when using the viewer to skip images, very good! o) Not sure about the hotkeys, what I use most often is pageup/down, fit to screen, 1:1, show information overlay, crop, save (as), delete, fullscreen toggle and mark.
If dlg.Control("editrange").focus = False Then
dlg.Control("editmain").focus = True
dlg.Control("editmain").SelectRange len(dlg.Control("editmain").value),-1
End If
=> feature request