Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Embedded windows - opinions please
Not a bug report, just a question.
For those of you that have done this, (I'm looking at you Colin), I'm wondering what's the motivation behind embedding a window within the shortcut bar?
What do you feel is the value add over simply adding the controls to the parent form itself?
For those of you that have done this, (I'm looking at you Colin), I'm wondering what's the motivation behind embedding a window within the shortcut bar?
What do you feel is the value add over simply adding the controls to the parent form itself?
Comments
I'll comment from a theorist perspective. When Kevin first revealed this little feature of the SRP ShortcutBar control, my first thought was that this would be a cool way to create reusable features. Just create forms dedicated for simple tasks and designed for embedding. In other words, mini-controls in-and-of themselves. Since they use their own commuter module, the behavior can be automated without re-writing code.
Now, I will be honest and admit I personally never implemented this idea in the apps I've worked on. I can't speak for the rest of the SRP team. For me, it ended up being less need to use the SRP ShortcutBar in this way.
What I have done on a number of occasions is create a BASIC+ wrapper for specific SRP controls, and thereby add functionality by way of unique properties, methods, and events. In other words, I created my own control using existing resources. My favorite has been the SRP BreadcrumbBar:
This is the SRP EditTable control. I just plop it down on a form sized and positioned the way I want, and the rest is completely managed via the SRP_BreadcrumbBar utility.
I have implemented the reusable features concept myself in the manner you describe but I use the Panel control to embed the form rather than the shortcutbar. The advantage? The panel takes up no more real estate on the parent than the embedded form requires whereas the shortcutbar requires its own space around the form. Secondly, the initialisation code is simpler; you don't have to really initialise the panel, you only need do the embed/setform component.
It's possible that it was just a matter of timing and the embed into the shortcutbar came into existence before the panel control and hence both now exist.
I was just wondering if the shortcutbar option had something further to offer that I hadn't considered. If perhaps you could collapse the group and effectively hide the embedded window, that would be a plus over the panel but I get the impression that's kind of pushing the boundaries a little too far. (I tried it yesterday and the results were less than desirable).
Still open for suggestions.
By the way, I like the breadcrumbbar. It's a clever twist on the edittable.
Since I have admitted to not having gone anywhere with embedded forms on the SRP ShortcutBar, I can't easily speak to its short-comings. (sorry).
I would have expected (or hoped) that collapsing groups would have been possible. But you touched on an item I had somewhat took for granted. That is, I would not consider the SRP ShortcutBar control to be an alternative over the SRP Panel control. I would only use it if I also needed the SRP ShortcutBar for other purposes. So, I assumed going into the discussion that there are going to be other groups with either shortcut items, other embedded forms, or both.
I simply started with a single group and embedded form with the intent, once that was working, to add further groups like you said.
I have a tree control which could potentially have hundreds of items so it needs to be as big/tall as is feasible. That said, it doesn't necessarily always need to be on display so I thought the shortcutbar would be a nice way to hide it as necessary and expose other forms or lists but it didn't work as I had hoped.
I'm just prototyping a new window at the moment so I will likely go through umpteen approaches before I find the right mix of what I like and what works but I won't throw the shortcutbar away without first asking the question.
Someone might come up with something that will prompt me to use it another way. :)
For reference, here's what happened when I tried to collapse the group:
Embedded it looks like this:
but then I collapse the group and this happens:
It's a stand alone form with just the tree control on it.
Didn't realise you could embed just a control without a form.
My current iteration has the tree directly on the parent but a shortcutbar could still be useful if there is an expectation of being able to collapse embedded forms even if I have to be selective about the types of controls/forms that are embedded.
I'll create a simpler version and if it too misbehaves then I'll send it through to you.
Not till some time next week though, so enjoy your weekend
will still send you something if I can work out exactly what to send.
Some further troubleshooting though has determined that the tree control is a furfy. I changed it to a datepicker and it behaved the same, drawing the calendar above the shortcutbar.
So I made the OLE control invisible and just threw on some OI controls with no intialising. They too appeared above the shortcutbar upon collapse.
I'll toy with a couple of other things and let you know if I stumble across anything else.
Sorry to intrude, but what is the SRP_BreadcrumbBar utility?