LiveCode Forums.

Thanks Jim!

That does appeal to my lazy side indeed! And it does have the benefit of not switching into browse mode...
I do like having discreet values as well though, so will test this along with my latest version (based on Bernd's suggestion): popover.livecode

And @Bernd - thank you for cluing me in on openControl/closeControl handlers... very helpful. Also curious about revIDESubscribe - there is no information about this in the dictionary not that much online other than it's used for plugins... is there a good source of into to read more on this and for available messages/subscriptions?
Also -- i replaced your 'red dot' graphic with an SVG widget, but it doesn't seem to respond to 'mouseEnter' messages, so i had to put that in a 'mouseMove' handler which does seem to work. Is this something particular to the SVG widget, do you know?

bn wrote: Sun Oct 25, 2020 9:41 pm I left the red dot graphic that shows up in edit mode only now if you move into it it will open the substack as palette. From there you can configure the popover.

Amazing, thanks Bernd!!!
That's really close to what i was thinking... only how would i add this to another stack?

I have a larger app i've been working on where i'll need 2-3 distinct popovers (basically to allow detailed viewing/editing/updating of items summarised in data grids). I've taken a bit of detour trying to get this workable.
With everything contained in a group, i can just copy/paste the group as a pseudo-widget and adjust it individually.

However with a palette stack as you've nicely shared, it would need to be a bit different... I guess the 'red dot' could pass the long id of the popoverWidget group and have the scripts reference that?
Downside is that it would require addition of both the substack and the group (as opposed to copying/pasting a group in only). But maybe that is the way to go...

stam wrote: Sun Oct 25, 2020 10:12 pm

bn wrote: Sun Oct 25, 2020 9:41 pm I left the red dot graphic that shows up in edit mode only now if you move into it it will open the substack as palette. From there you can configure the popover.

Amazing, thanks Bernd!!!
That's really close to what i was thinking... only how would i add this to another stack?

I have a larger app i've been working on where i'll need 2-3 distinct popovers (basically to allow detailed viewing/editing/updating of items summarised in data grids). I've taken a bit of detour trying to get this workable.
With everything contained in a group, i can just copy/paste the group as a pseudo-widget and adjust it individually.

However with a palette stack as you've nicely shared, it would need to be a bit different... I guess the 'red dot' could pass the long id of the popoverWidget group and have the scripts reference that?
Downside is that it would require addition of both the substack and the group (as opposed to copying/pasting a group in only). But maybe that is the way to go...

To attach a substack to another stack is relatively straightforward. Clone (see dictionary) the substack and then attach it via the properties inspector to the new main stack. You should give it an unique name because Livecode does not like two stacks of the same name. Adjust the red dot accordingly.

There are many ways to inform the palette of more groups. The substack could query the current card of the mainstack for groups that indicates they are a popover. That could be the name or a a custom property or whatever that makes them distinct. The controller could gather the long ids and e.g. present an option menu.
Or the red dot could send the long id of its group to the controller which then sets the appropriate long id for the "sRealMe" (you would have to add a handler to the controller that reacts to the message send by the red dot which in turn sets the script local "sRealMe".

If you use the controller substack you don't need the code in the pop over group script. The logic moved to the controller substack but all custom properties etc. would be set on the pop over group.

This would even make code changes to the logic of the pop over groups easier because the logic is in the controller and the same for all groups.

The publish and subscribe mechanism is not exposed and used by the IDE internally and for plug-ins. And that is why it is not documented.
If you are interested in the messages they are listed in stack revIDELibrary line 1533.
I would stay away from them except maybe for the one I used for the red dot because it was the easiest way for me to avoid the keyboard.
Although Ali Lloyd, the LC engineer that coded the current implementation of publish and subscribe is not opposed to the use of it "off-label".

Kind regards
Bernd

you're a genius, thanks Bernd!

Thanks everyone for the invaluable advice (and special thanks to Bernd)...
The aim was to create a simulation of popovers who's settings can be altered as needed.

The final palette stack that can add popovers to a card of the topstack and can very easily edit any of the existing popovers.
Easy to add as a plugin (which is how i'm using it) by dropping into plugins folder.


The API has been expanded so can be modified in code dynamically if needed:
- setSide pSide: left/top/right/bottom
- setLocation pPercentageOfLength: location of arrow along chosen side
- scaleArrow pFactor: scales arrow size to the length of chosen side
- setCornerRadius pRadius
- setFillColor pColor
- setLineColor pColor
- setLineSize pSize

All scripts are in the card script except for the scripts required to resize the popover control correctly which are in the group script of the popover and a minor script in 'edit settings' image. The included documentation is minimal, can expand if needed.

Dowload: skPopover.livecode

The only real issue is the line thickness - a large line size ( > 6) causes artefacts in the tips of the arrow mainly because I've used existing vector shapes - I know it's possible to directly draw shapes but requires some figuring out on how to draw the round rects, arrows etc. Probably for a much later version...

Any feedback welcome! (especially if any showstoppers!)

Bernd- the publish / subscribe mechanism was changed recently to allow any messages, not just the artificially limited revIDEMessages list.
The first line in revIDEMessageIsValid in the revLibrary stack makes that explicit. The most important thing is to balance the subscribe and unsubscribe calls.