Apparent Bug In {digfolder}

I've been getting very confusing results using {digfolder} for user input. Eventually I played around with this very simple test button, and it seems to me there's a bug in the command.

@set fldr=xyz
@set fldr={dlgfolder|Choose folder|abc}
Clipboard SET {$fldr}

Expectation 1:
Selecting an item via the displayed folder tree should put it into the clipboard.
Result:
Works as expected. :smiley:

Expectation 2:
Clicking OK should leave abc\ on the clipboard.
Result:
Works as expected, but only after the button has been used a few times. If I click the button straight after opening the default lister, and click OK, it puts "C:\Documents and Settings\DT\Desktop" in the clipboard. :confused:

Expectation 3:
Clicking Cancel should leave xyz in the clipboard.
Result:
This never works as expected. :cry:

Cancel clears the window but then it reappears, and in a non-working form. Cancel in window 1 followed by OK in window 2 puts xyz in the clipboard, which is what the first Cancel should have done on its own.

Strangest of all: if you Cancel in both windows the routine makes no change to the clipboard at all. But this means that the second line in the script has inhibited the one that came before it.

Should we expect lines in the command editor to run sequentially, or not? If not then I feel I'm missing some key info about how Opus works.

You can't do this. If you cancel the dialog then it should cancel the entire button and not run the Clipboard command at all. As a side effect of that, there's no point having two @set statements for the same variable and I'm not sure what happens if you do, but that may explain the weirdness you're seeing with the other cases.

As ever - thanks for coming back and helping. Take away the first line and Cancel still makes it bounce back but if I leave only the {dlgfolder} line on its own it's ok - but not much use for what I wanted it to do.

Confusion is setting in tho'. When you say 'You can't do this', are you quoting from hard experience or is this explained somewhere? Haven't read every word of the manual yet (altho' it's beginning to feel like it) but I've studied Internal Commands Summary and Command Control Codes pretty intensively.

I've seen lots of examples of buttons with multiple lines in the forum. How's one to know which you can use and which not? Trial and error is extremely laborious...

It now seems clear that I shouldn't think of Opus commands as running sequentially like lines in a batch file - but if not how should one view them?

(By the way, the reason for the two @set lines was to try to get a handle on what was happening. I though the first one would tell me if the second one had run or not).

Yeah, I see that too. I don't think that should happen so I've reported it to GPSoftware.

I'm not sure if it's in the manual or not but if you think about how buttons that request user input work, most of them will fall apart if the user input isn't given so it makes sense that Opus cancels the entire button if Cancel is clicked.

[quote]I've seen lots of examples of buttons with multiple lines in the forum. How's one to know which you can use and which not? Trial and error is extremely laborious...

[...]

(By the way, the reason for the two @set lines was to try to get a handle on what was happening. I though the first one would tell me if the second one had run or not).[/quote]
The two @set commands being wrong is not because the command has multiple lines. Multiple line commands are generally fine (provided the names of the selected files don't change between lines). The reason it's wrong is because there's no point to the first @set command because the second @set command will always overwrite the same variable -- or cancel the operation completely -- at least if Opus is behaving correctly. The dialog appearing twice suggests there may be something odd going on that shouldn't be.

Glad you agree there might be an issue here.

Reasonable enough. The problem here is that the cancellation isn't happening. If there's another command after the line containing {dlgfolder}, sometimes the same (but non-functional) dialog box bounces back, but sometimes the unexpected second box is the simpler default box for 'CreateFolder' (and this one is functional).

Here's an example (can't see why it shouldn't be 'legal', but I'm prepared for bad news :wink:):

CreateFolder NAME {dlgfolder|Choose folder for the pictures|/mypictures{date|yyyy-MM-dd} Description} READAUTO=dual
Set TREE=On
@confirm Rename and transfer files?|Yes|No

Here if you select Cancel in the 'proper' dialog box, it bounces back with a fully-functional simple new folder window ('enter name of folder you want to create'). But remove the Set Tree line and it works as expected: you get just one folder dialog box and Cancel terminates the whole thing.

Do tell me if I'm getting boring on this subject... (It's just that unexpected behaviour in a command is especially dispiriting when you're a novice and not too sure what you're doing anyway).

Thanks. That's probably part of the same problem with {dlgfolder} not cancelling buttons properly but I'll add it on to my report to make sure both cases get tested.

Another problem with {dlgopen} not solved again in 9.1.0.1... :wink:

resource.dopus.com/viewtopic.php ... ht=dlgopen

[quote="AlbatorIV"]Another problem with {dlgopen} not solved again in 9.1.0.1... :wink:

resource.dopus.com/viewtopic.php ... ht=dlgopen[/quote]
I don't see the connection, apart from them both having to do with {dlg*} command codes.

I think we can assume that 9.1.0.1 was released ASAP to solve the 64-bit drag & drop crash bug. No need to remind the forum if every other reported bug hasn't been fixed yet. :slight_smile: