Problem with "@ifsel:else"

Help & Support
1

As I mostly use a pretty minimal lister window which sits in a corner of my laptop screen (only consuming approx. 1/4 th of my screen space), I’m often using a button to open an external minimal listener (without directory tree etc.) just to have a quick, broader view on a folder. The button has the following statements:

@ifsel:dirs
GO FROMSEL NEW=100,10,1600,600,notree,nodual,noviewpane,noutilitypanel,nometapane LAYOUT=Single VIEW=Details NOSCRIPT
@ifsel:else
GO CURRENT NEW=100,10,1600,600,notree,nodual,noviewpane,noutilitypanel,nometapane LAYOUT=Single VIEW=Details NOSCRIPT

This is two times almost the same command. The first condition is invoked when I selected a folder - in which case it shows me the content of that folder - hence the “FROMSEL” directive. This works perfectly. This is perfect.

If no folder is selected, the “ifsel:else” condition applies, which should show in big format the contents of the folder that I already have open (hence “CURRENT” instead of “FROMSEL” - the only difference).

Problem is: when nothing is selected, the second statement is not being executed. It only works if I select at least 1 file. That doesn’t seem correct to me. And “ifsel:common” is not the solution either - it opens 2 windows when I have a folder selected - which is to be expected).

Could this be a little bug in the implementation?

For the moment, I changed this to work with javascript scripting - which allowed me to correctly detect the selection of a folder and implement a correct if/else condition:

function OnClick(clickData)
{
	var srcTab = clickData.func.sourcetab;
	var cmd = clickData.func.command;
    var selected = clickData.func.sourcetab.selected_dirs;
	var itemcount = selected.count;
	if (itemcount > 0) {
		cmd.RunCommand("GO FROMSEL NEW=100,10,1600,600,notree,nodual,noviewpane,noutilitypanel,nometapane LAYOUT=Single VIEW=Details NOSCRIPT");
	} else {
		cmd.RunCommand("GO CURRENT NEW=100,10,1600,600,notree,nodual,noviewpane,noutilitypanel,nometapane LAYOUT=Single VIEW=Details NOSCRIPT");
	}
}

So it isn’t anymore an issue for me. Still, it looks to me like the “ifsel:else” implementation shows inconsistent behaviour.

2

Bits of your post seem messed up somehow. For example:

@ifselifselifselifselifselifselifselifsel:else

According to docum@ifselntat@ifselifselon, @ifsel:else must@i@ifselheselhebe@ifselinvo@ifseled if @ifselhe first @@ifselfsel@ifseldoes n@ifselt apply.

Could you edit it so it makes sense?

3

I couldn’t correct it properly until I removed the acroll signs. In fact, I think a space behind each acroll (in normal text, outside ‘code’) would have done the trick. I guess it’s because the acroll expects following characters to refer to a name of a forum member.

4

Now that I rethink it, my assumption is that in contrast to “if”, the “ifsel” condition always expects something to be selected. If so, one could see a certain logic in it, when compared to simply “if”.

But, more in general, I still find it not truly logical, and certainly unproductive. And once you used “ifsel”, you can’t use “if:else” either (I tried that) - because obviously you are caught in the “ifsel” logic.

5

I don't think that's correct. What do you see if you run this function? (open the log via Help > Logs > Script Log)

@ifsel:dirs
@output dirs
@ifsel:else
@output else

For me that prints "else" if I have nothing selected at all, as well as if there are only files selected.

1 Like
6

You are right: with nothing selected, the output is ‘else’.

This proves that my last conclusion was incorrect c.q. speculative.

But that doesn’t make it work for opening the lister in my example. It its simplest form:

@ifsel:dirs
GO FROMSEL NEW
@ifsel:else
GO CURRENT NEW

The else does not work without a file being selected.

(Yet, I am not in need of a solution, as I said - I just mention something odd’s going on there).

7

Ok, looking into this, it's actually nothing to do with the @ifsel construct. The problem is caused by the Go FROMSEL command.

Opus sees that command and automatically flags the function as requiring selected files or folders.

This calculation is done before any of the conditional stuff is looked at, so stops the function running even if the actual command that gets executed doesn't require it.

In the next update we'll add a way to override this via the @requires directive.

1 Like
8

Okay. But are you sure that an “override” is a good solution? Speaking intuitively, I would suggest it’s rather something within Go FROMSEL that seems in need of adaptation.