Should Goto always reset the filter?

[admin]

Talking about UDC "Go To" and scripting "goto". I'd say when you want to go somewhere using these commands, you either want go to the unfiltered location or set a new filter. You hardly want to keep any current filter (which is unknown to you in the moment you write the command).

So, I suggest if the location is stated without any filter then any current filters should be removed (as if it would be "location|").

Okay?

[TheQwerty]

Hmm.. if you go that way can I suggest a change to the Filter command to allow turning the filter on without changing it.

Perhaps change Filter [Pattern] to Filter [-|+||Pattern]

So we could do:
Filter -
or
Filter
To turn off the current filter.

Filter +
To turn on the current filter.

Filter |*.jpg
To activate a new filter of "*.jpg"

It's a little confusing writing the documentation but using a | to start a pattern keeps with the quick filters format, and still allows us to use - or + as the pattern.

[admin]

Hmm.. if you go that way can I suggest a change to the Filter command to allow turning the filter on without changing it.

::#355 = View / Current Tab / Toggle No/Last Visual Filter

[TheQwerty]

Fine can we have a new command?
::FilterToggle = ::#355

[admin]

Fine can we have a new command?
::FilterToggle = ::#355

Maybe we can solve it with a parameter? E.g. ::Filter \ or ::Filter / ...

For what do you need it? I find toggles unpractical for scripting.

[TheQwerty]

Fine can we have a new command?
::FilterToggle = ::#355

Maybe we can solve it with a parameter? E.g. ::Filter \ or ::Filter / ...

For what do you need it? I find toggles unpractical for scripting.

Actually forget everything I've said in this thread.

I do oppose to this idea.

As it stands I can easily remove the filter from the UDC or goto command myself, but there is no good way for me to re-apply the filter that's in use if you automatically remove it.

[jacky]

Okay?

hum, no.

I don't think I like this idea. Because sometimes I do browse around and I have a VF set and I expect it to stay on, very useful for quick "manual search job". Besides, how would one get to disable any VF then ?

Now reading your first post again I need to ask : you really mean only UDC and script, not any other way to call the goto feature ?
- If you mean all calls to go to, then I'm definitely against it.
- If you do mean only UDC/Scripting, then I find it quite odd, as it's inconsistency and a source for confusion : goto works one way, except for UDC/Scripting ?
Despite that, I guess most the times when I browse around with a VF on, I use Tree, Favorites or Catalog, so I guess I would be fine. Im not sure how others would feel, when they have other way to work...

But if you are to do it, I would think that :

- command filter should allow to turn it on/off, like toggle only we "decide" the state. Eg: "::filter 0" would turn it off (to filter items with a zero, we can just quote: ::filter "0")

- there should be a way, extra param?, to do a goto and ask to let VF unchnaged. Because today we can do a goto and decide : no change, turn it off, set specified VF.

[admin]

Fine can we have a new command?
::FilterToggle = ::#355

Maybe we can solve it with a parameter? E.g. ::Filter \ or ::Filter / ...

For what do you need it? I find toggles unpractical for scripting.

Actually forget everything I've said in this thread.

I do oppose to this idea.

As it stands I can easily remove the filter from the UDC or goto command myself, but there is no good way for me to re-apply the filter that's in use if you automatically remove it.

My reason to suggest a change is: I see myself suffixing locations with "|" only to turn off any filter (or start every script with "filter;") . Not good. I believe the standard desire is "filter off" when you go to a new place. Whereas "keep filter" is rather an exceptional thing in the context of scripting. The exceptional things should always be harder to get. That's a universal law of work economy. So I'll look for a way to say "Goto X and keep any VF".

[admin]

...No!...

Yes, I see the inconsistency. You are right, it would be confusing. I think about it. There are many options. E.g. a new command ("go"?) to browse a location unfiltered. Or add a parameter to goto to optionally open the location in a new tab (which is always unfiltered).