User asked to show an action ONLY if user selects category (not the document). If user selects a document, action should be hidden.
Is it possible?
I couldn’t find anything about this.
Any help is really appreciated.
Thanks,
Olga
User asked to show an action ONLY if user selects category (not the document). If user selects a document, action should be hidden.
Is it possible?
I couldn’t find anything about this.
Any help is really appreciated.
Thanks,
Olga
Subject: Yes!
Yes (just learned this trick yesterday).
Check out @GetViewInfo. It lets you ‘read’ a value from the selected row, rather like turning a view into rows/columns and picking one column to read. Use it in a view action hide/when formula.
Set the view to ‘update at document change’.
The two together allow you to turn actions on and off based on the row selected.
It is so very cool!
HTH
Doug
Subject: Thanks, but…
Thank you for this great idea. I’ll try it rught away.
It’s just that I can’t find this property in view (to update on document change). I looked through all view properties.
which tab is it on?
Subject: RE: Thanks, but…
‘i’ tab.Evaluate actions for every document change. It’s the 6th checkbox from the top in 6.5.4
Subject: Thanks, it works!!!
Thank you very much.
Subject: RE: Thanks, it works!!!
Your welcome. I just discovered this yesterday so the timing of your question was good.
I love this little trick - now I can hide actions that require the user highlight a document for the action to be valid - it saves me writing code to tell the user they’re in the wrong spot.
Enjoy.
Doug
Subject: RE: Thanks, it works!!!
With the view property to evaluate actions on every document change, you can even refer to fields, that are not in the view (like simply ask for Form = “”). But using @GetViewInfo is probably better, as it should not need to access the actual item in the actual document (at least as far as I understand it).
Subject: And the cool stuff just keeps coming!
Thank you!
I’ll play with this and see if there are any advantages/disadvantages to either approach.
Either way, it’s a great way to 'show ‘em what they can do and nothing they can’t’. Darn Chris B and Nathan F for making me think about my UI design… I’ve always known my stuff was UBF (ugly but functional) but now I see it’s really UBFAC (ugly but functional and confusing).
Off to play.
Referencing a field works like a charm. I actually think it’s simpler than using GetViewInfo, at least it’s easier to write. I probably need to see if there is any detectable speed difference, but I’m guessing that the difference is small.
Subject: RE: And the cool stuff just keeps coming!
I never tried to find a way for a shoot-out between the two. Ticking that view property slows it down considerably anyway (so it’s probably not well suited to a $All view. Most probably it really makes no difference.
While we’re at it: Did you have a look at @UpdateFormulaContext yet? It’s amazing what you can do with formulas only in Notes 6 and up!
Subject: RE: And the cool stuff just keeps coming!
Sorry for lag responding - work spiked up in the last couple of weeks and this is the first chance I’ve had to get back.
Yes, I ran into this at either Chris Blatnick or Nathan Freeman’s sites. It makes a ton of code easier to write. In the past, if I was in DbOne and needed to create a document in DbTwo based on content from DbOne, it was either LS or passing data to the ini file then calling an agent in DbTwo to use the ini values and create the document. Now, I can write all the code in DbOne and just flip the context when needed - soooo much easier.
Well, back at it and thanks again for the tips.