Acting on multiple documents in an embedded view
So after Chris' excellent post on his CoolMail
demo where he uses an embedded
editor to fake an action bar outside
the view's context, I started thinking about how to address one of the
respondents request for the action to work on multiple documents.
The problem is, if you want to have the controller for the behavior outside the embedded view, there's no way to get access to the context of the view itself. There's no way to take action against the document collection that's selected in the view. The current UIView object doesn't give you the embedded context. Any agent you attempt to run from the wrapper form runs with the UIDocument as the selection set, not the selected documents in the view.
I tried @SetTargetFrame to see if I could set the target to be the embedded view itself, but no luck. Plus, you have a very short list of operations that you can perform after an @SetTargetFrame, and [ToolsRunMacro] is not among them.
So, Chris comes back on Monday with a new trick to handle expand/collapse requirements in embeds. And in it, he does something that didn't occur to me -- running additional @Command calls AFTER one of the limited set of functions available.
The unexpected behavior is that using [OpenView] on a tiny frame opens the view with the selection set intact. So if we then do a [ToolsRunMacro] in that frame, we process the selection set from the embedded view's context.
Read on for full details
The problem is, if you want to have the controller for the behavior outside the embedded view, there's no way to get access to the context of the view itself. There's no way to take action against the document collection that's selected in the view. The current UIView object doesn't give you the embedded context. Any agent you attempt to run from the wrapper form runs with the UIDocument as the selection set, not the selected documents in the view.
I tried @SetTargetFrame to see if I could set the target to be the embedded view itself, but no luck. Plus, you have a very short list of operations that you can perform after an @SetTargetFrame, and [ToolsRunMacro] is not among them.
So, Chris comes back on Monday with a new trick to handle expand/collapse requirements in embeds. And in it, he does something that didn't occur to me -- running additional @Command calls AFTER one of the limited set of functions available.
The unexpected behavior is that using [OpenView] on a tiny frame opens the view with the selection set intact. So if we then do a [ToolsRunMacro] in that frame, we process the selection set from the embedded view's context.
Read on for full details
So here's our embedded search folder from a few days ago. I've already run a search, and I see my results set...
Now I want to mark the selected docs as favorites. I just click the Mark as Favorites action, which is a hotspot in the container form, NOT the view's action bar...
To do this, we first have a frameset with a tiny frame at the top for loading the folder, called "SearchSecretContext"...
I like to make these 1 pixel instead of 0, because I haven't figured out to select a frame that's 0 pixels. Please note that this should be set to "Allow Resizing" of "no". Consider that a typo in my screenshot...
The frameset is configured to show our search form in the primary window, but it really doesn't have to be. Using the frameset autowrapper will force it anyway. Which means I could reuse this same wrapper model on a number of different form/embedded view combinations. The key thing here is that we've got a hidden frame reference against which we can do all the stuff that would normally be ugly for the user.
Then we set the form to automagically put itself into that frameset whenever it's composed...
Finally, the simple hotspot code that runs the agent. Note that it's pointing to our hidden frame, where it does an OpenView on the folder that is already embedded on the form. That makes the subsequent agent call use the selection set from the embedded version...
As a bonus, here's the code for populating the embedded folder itself. This is what the form executes when you click on the checkmark next to the search field...
And here's the code in the QueryClose of the form that gets everything out of the folder, so it's empty on the next search...
A couple of final notes, since this will come up in the comments...
Yes, I'm using hotspots, but this is just a triggered action, so it could be ANYTHING that set off the executing events. I could use a keyword list with an onChange event, for instance. Anything where I can execute @function or LS code works.
Yes, I tried some stuff with client-based Javascript to get this to work. No joy on that one. I could find NO way to get the container form to be aware of the embedded element's context. However, going the other way is something I've demonstrated here before.
Could you do this exactly like Chris' original demo, where the trigger actions are in an embedded editor, so it acts on multiples if you select multiples, even though you're altering the contents of the currently selected element? Yes. It would be a pain to get it to behave reliably, though. You'd have to figure out whether the user intended to modify the current CARET position document (the one rendered in the editor) or the SELECTED COLLECTION in the embedded view. Since you could check off 5 documents, then position the caret on a 6th one, you could easily get confused. I think you'd have a real tough time creating a user vector that combined the ideas but was still easily understood.
Why didn't I use any layers for this? Good question! Maybe I can get the the actions to somehow float over the embedded folder! Perhaps next time.
Comments
Posted by John Head At 07:51:06 PM On 03/07/2007 | - Website - |
Posted by Chris Blatnick At 08:46:19 PM On 03/07/2007 | - Website - |
Posted by Esther Strom At 06:12:21 PM On 03/08/2007 | - Website - |
i only hope this selection thing in an other frame will work the same in current and future releases...
Posted by Markus Koller At 08:30:31 AM On 03/16/2007 | - Website - |
internet saved me
you just saved me
thanks a lot for sharing this trick
Posted by nico At 08:37:49 AM On 04/12/2007 | - Website - |
I am trying to do this using views instead of folders but having no luck! Any suggestions?
Posted by stephen pengilley At 04:31:41 AM On 04/18/2007 | - Website - |
I'm not afraid to beg.
Can you provide a very simple schematic of what gets created and where it goes?
Thanks.
Doug
Here's where I quit:
FormA includes:
Embedded ViewA
Launch tab shows FrameSetA with frameBottom as the frame to open.
Hotspot with code:
@SetTargetFrame("frameTop");
@Command([ToolsRunMacro];"(UpdateTestField2)");
@Command([RefreshFrame];"frameBottom")
FrameSetA has frameTop and frameBottom
frameTop is ViewA, size 0%
frameBottom is FormA, size 100%
(UpdateTestField2)is a simple agent that sets TestField2 to a string value.
When I open FormA, I see the embedded view, can check off multiple docs, hit the hotspot, and 'poof', nothing happens. Acutally, I get an error (document not saved) if I hit the hotspot unless I've saved FormA.
What am I missing?
Posted by Doug Finner At 02:47:59 PM On 04/20/2007 | - Website - |
Not sure if this matters, but I'm running 6.5.4.
OK, it's time for the weekend...I'll check back next week.
Thanks.
Doug
Posted by Doug Finner At 03:19:05 PM On 04/20/2007 | - Website - |
Hotspot:
@SetTargetFrame("frameTop");
@Command([OpenView];"vwEmbeddedSingleCat");
@Command([ToolsRunMacro];"(UpdateTestField2)")
(UpdateTestField2) code:
@SetField("FieldName";@Text(@Now));
Agent runs on all selected documents.
Frameset has two frames. Both frames are empty with no default target for links defined (doesn't matter if the top frame has the bottom frame as the target).
Still confused in NH. Any tips are appreciated.
Doug
Posted by Doug Finner At 07:38:06 AM On 04/24/2007 | - Website - |
I set the lower frame of the frameset to be a URL (ie in the 'hidden' frame used to process docs nothing is visible).
I added an @Function agent to set a field called Subject. If I check the docs in the embedded view, the error is that the agent fails because no documents are selected.
If I modify the frameset to display the embedded view and check off docs in the embedded view (in the upper frame, not in the lower 'hidden' frame), same error.
I tried doing a LS agent that just counted selected doc, I get a count of 0.
If I check the document in the lower frame, the docs are updated just fine. Once I've done this one time, I can uncheck anything in the lower frame, check docs in the embedded view and the code works ??
What's even more fun is that as I start doing things in Chris' design like turn on the selection margin of the embedded view and add a hotspot to run the agent, the overall behavior of the app gets whacky - if the db is set to open in Chris' original 'Cool Docs' frameset, I get two tabs opened when I open the db - a view then the frameset. The video monitor shows the view on the first of the two tabs but the frameset tab, the second of the new tabs, is light colored (ie 'selected'). If I click the 2nd tab, I see the intended launch location.
And now I'm going to sound like every user who ever denied doing anything wrong...but I'm not doing anything wrong!
OK, I'm off this for a bit - this function would be great but it looks a bit risky for right now - I'm still wondering if this is a version thing.
Later.
Doug
Posted by Doug Finner At 09:45:17 AM On 05/21/2007 | - Website - |
Now a couple of points I noted in implementing this, in case they are any help to anyone.
The reason why I needed it was because I am using two embedded views in an Invoice, where removing items from the Invoice needs to be reflected in the totals. When you use actions in the embedded view, it does not seem to be possible to refresh the container form - all my attempts lead to interesting crashes. I am currently using Notes 7.02
First off, it seems to be important to clear the "dummy" frame after you have used it, using something like @PostedCommand([OpenPage] ; "blank") at the end. (Note: I have a predefined blank page in the database). Before I did this, the selections would not get picked up on the second or subsequent tries. Also, the frame appears needs to be at least 1 pixel high, or the selection is not picked up.
The thing that did trip me up initially was not using the option of having the form opening in a frameset (see the fifth screenshot above). Since I already had a dummy frame (with an empty view in it, necessary to ensure that the database does not open in a new window when opened from a SmartIcon - it seems that an open view indicates to Notes that the database is open - can't find anything else that works!) I tried to use this, to no avail. Like Doug above, the view would open, with the selection evident, but the agent would return an error claiming that nothing was selected. I can't think of any reason why it should matter, but it seems to.
The only slight problem I have is that I don't seem to be able to trap the error of a user failing to select anything. I am using a LotusScript agent, but the error comes up before the code executes if there is nothing selected. However, the message is more user friendly than most, so I think the client will be happy enough.
Thanks again for a great idea!
Posted by VladG At 11:03:54 AM On 05/28/2007 | - Website - |
First of all - excellent stuff!! So thanks for that!
I am trying to make it work for embedded single category views but no joy
Normal embedded view works though but then thats not what I want to have - my embedded view should only show docs related to the main doc.
Any ideas?
Thanks
A
Posted by Arshad Khalid At 10:48:49 AM On 05/16/2008 | - Website - |
Posted by Zinahe At 08:34:27 AM On 06/27/2008 | - Website - |