Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Layer upon layer upon layer

This is a best practices or do you think it's viable question really so unqualified and untested answers are acceptable. ;-) After opinions really.

What's the likelihood of success or torment with using embedded windows that contain embedded windows?

Haven't tried it, just fleshing out ideas.

I have developed some controls that I want to use in multiple places. So I go the extra step of placing the control on a window all of it's own and make it effectively self contained basically as if it is an object itself. That way I can re-use the same control on a number of different windows by placing a panel control on the new window and with a one liner embedding the 'object' into the panel on the window. The new window now has a control that looks and works the same everywhere the user sees it, with nothing more than a single line in the create event.
One of these objects I've just created is a shortcutbar. The thought then occurred to me, what if within the shortcutbar I embedded a window with some simple controls. Assuming that first step works, would everything continue to work when I then used the setform method to embed the shortcutbar window into a panel or would the world just blow up in my face?

Of course I could try it but would rather hear first if there was some major reasons why this would be a bad idea. Especially if those reasons may not make themselves apparent in testing.

Hope I haven't been too confusing.


  • I suppose this theoretically doable, but this only makes (some) sense to me if you created a re-usable control that is composed of several more controls. To have a panel with a single control doesn't make much sense to me since you could acheive the same re-usability by having a stored procedure that does all the control's setup for you.

    Case in point, we have an EditTable manager routine that we call for all our tables during a promoted CREATE event to give every table the same look and feel and to set up common features.

    Even if you do only use this for complex user controls, I'm not convinced it's worth the effort in OI due to the way OI deals with data-binding. Sometimes it's just better to copy/paste a set of controls from one form to another and maybe place common code in a stored procedure that each form's commuter module can reference.

    I do prefer the ideology behind re-using complex user interfaces, but OI is not well suited to that task. I have encountered multiple systems that attempted to incorporate elements from other environments (such as object-orientation) only to butcher the BASIC+ language and leave future developers scratching their heads. I think it's always best to avoid over engineering whenever possible because future you (and future progeny) have to work with it. If you can make this work pretty cleanly (and document it), then it's not a bad idea, but I wonder if the return on investment will be truly worthwhile in a development environment that resists that kind of re-use.

    Technically, no one at SRP has attempted multi-tier form embedding. So, give it a go and let us know. :-)
  • We share similar approaches.
    I have a setup routine for virtually all of your controls so that they can each have the same look and feel throughout the app. Assuming your edittable manager is a similar concept.

    What I'm doing here is just one step further whereby I want certain events to do things without the parent form being any the wiser.
    This is an example

    The calendar and the next/previous buttons are an embedded OI form. The calendar itself is an SRP edittable. The next/previous buttons change the month and repaint the table so it displays the correct month/shading etc similar to an Outlook schedule.
    I will use this in a window where I want to display any kind of data in a month view. The parent window knows about the data and sends it to the calendar window in an array, the same syntax as any other set_property call. The calendar window then takes over and displays it accordingly and it doesn't care about the content, just that the array is in the right format.
    When the user changes the month via the buttons, the parent commuter receives an event of which the parameters are the date range that's on display. That way the parent window (that knows what the data is) can do it's select, build it's array and then set_property().

    If I find myself an excuse to try multi tier embedding I'll let you know how it goes. Just food for thought at the moment.
    Kind of creating a control where one doesn't already exist but without doing too much so as to face the problems you've correctly identified.
    I think I'm lucky in that sense though. Smart enough to code a bit but not so smart so as to over engineer.
  • edited January 2016
    This one is an example that prompted the curiosity about the multi tier embedding.
    In this case, at the moment at least, it is just one control so I heed your concerns about embedding a single control when you could just place the control itself on the window.

    Here's why I didn't though. With this window, the shortcutbar is embedded in a panel. Whilst I could just place the shortcutbar on the parent window instead of the panel, there are some things the shortcutbar does that I don't want the parent window to have to worry about. In this case, the embedded control does know about it's own data. It displays data from a header file. The only thing the parent window knows is if the user clicks on an item (not a group or anywhere else), the parent window receives an OnClick event from its panel control and the only parameter is the key to the header file. So the parent window knows the user has clicked on a header and loads the corresponding detail into the reporttable on the right.

    If the user clicked on the group that says "Load More..." the shortcutbar knows how to retrieve and display the previous twelve months of data. The parent window is none the wiser that anything has happened.
    In this example, the shortcutbar is displaying invoicing data but it is also designed to show payroll data depending on the initial createparam. That way the control looks and works the same throughout the app in billing and payroll windows and in processing windows, reporting windows wherever we may have previously used an OI popup or a tree control for a similar selection.
    It just goes that step further than just this is how a shortcutbar should look but rather this is how a header table (obviously with date relevance) should be supplied to the user.

    By all means, knock me over the head, call me a fool and say you should have done it this way...
    I'm the first to admit I do get lost in my own creativity and excitement sometimes.
  • Mark,

    What you are essentially doing is rolling out your own control viz-a-viz a combination of other controls and relying upon the SRP Panel control to be your host. In princple this is conceptually the same concept as the way the Form Designer's OLE control acts as a host for 3rd party ActiveX controls.

    This concept is one that Kevin and I have discussed but I don't think we have ever implemented this in practice. The closest I've come to is creating a BASIC+ wrapper around one of our OLE controls so that it gets setup and behaves like a a new control. The one example I have in mind is the SRP BreadcrumbBar. Given that I needed the features of a standard breadcrumb bar but I was unable to prevail upon Kevin's time to build one, I just created one using the SRP EditTable.

    The developer is still required to place an SRP EditTable control on a form. Then in the form's commuter calls the SRP_BreadcrumbBar routine passing in various methods and arguments to set it up, respond to its own events, and even send notifications to the parent form as needed. So it doesn't behave as isolated as what you are doing, but the inspirational intent is there.
  • Mark,

    This... is... awesome.

    So, when you first proposed the idea, I envisioned very simple controls, but this makes total sense. Really, this shortcut control is conceptually a form unto itself anyway. The Panel control allows you to drop it in multiple forms rather than having it float around awkwardly.

    I like it. Well done. That deserves a slow clap.
  • Don,

    Conceptually, yes that was what I was going for. Unfortunately for me, once I discuss it, even just with myself, I can't sleep until I've at least tried it. Then once I've tried it and providing it worked I am then constantly looking for an excuse to implement it. Your description of the creation of the breadcrumbbar sounds similar though I'm sure you had an actual requirement before jumping into the code.

    Kevin, pause that clap for a moment whilst you consider this. The link to the original post title is this.
    What if, instead of the 'Load More...' group header just doing it's thing, the group itself was to have an embedded form with further selection controls such as a start and finish date for example.
    That way the user could theoretically choose the period they want to see in the shortcutbar, again without the parent form having to do anything.

    I don't know that I really want to do this mind you but was just wondering if a form embedded within the shortcutbar which was itself a form embedded into the panel would create panic and confusion the world over.
Sign In or Register to comment.