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?

Comments

  • Mark,

    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.
  • Thanks for the insight Don.
    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.
  • Mark,

    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.
  • edited January 2016
    You were spot on with your assumption as to where I was thinking to take it.
    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:
    image

    but then I collapse the group and this happens:

    image



  • Is the tree set to auto size in any way? Is this just a tree control or is it a tree control on a stand alone form?
  • No, it's not set to autosize.
    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.
  • Actually, no, you can't. At least, you shouldn't. That's why I asked. I'll have to experiment on my end to see what I can find out. I will say that embedding forms is a finicky process. There are all kinds of problems due to the fact that OI assumes forms are not children.
  • Won't hold you to anything but do you think it could have something to do with the type of control/s on the embedded 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 have a small form with just a tree control, but it behaves nicely. This might be a situation in which I need the setup of your tree control and any logic in the tree's form as well, if there is any.
  • Ok. As usual, all part of a bigger picture.
    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
  • Hey Kevin,

    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.
  • And I didn't mention I'm using Windows10, in case that's the culprit
  • Try 4.0.2 RC24 to see if this issue is finally resolved without causing other issues. I had to rewrite a bit of rendering logic.
  • Don,
    Sorry to intrude, but what is the SRP_BreadcrumbBar utility?
  • Barry - I'm assuming you are aware of this from an earlier post in this thread, correct? I thought my post and screenshot were self-explanatory. To summarize: it's a BASIC+ routine I wrote that uses the SRP EditTable control to emulate the functionality of a breadcrumb bar. My goal was to emulate the look and feel of the Windows Explorer breadcrumb bar. I designed the routine so that it was self-sufficient. That is, my commuter module doesn't know anything about the SRP EditTable control. It only communicates via the BASIC+ routine. I wrote this routine so the developer could set properties, send methods, and send events back to the caller. Thus, it behaves as if it were a new control, even though it really isn't.
  • Sorry, 'SRP_BreadcrumbBar utility' sounded like something that was downloadable and a search on srp wiki didn't find it. Also I didnt know what a breadcrumb bar was, so thanks for the link.
  • Yeah...I only brought it up because this thread was about creating reusable components. The utility itself does ship with our full SRP FrameWorks product. I've toyed with the idea of making it available to the public at large but since it uses the SRP EditTable, it isn't something that anybody can download by itself and utilize.
  • Ok, no problem, I understand.
Sign In or Register to comment.