Container tabpanel

Classic Servoy
21

Ric, wish I could make this year’s Servoy World … we’ll see (existing commitments in that time frame at present). Rumor has it that Amsterdam is a good place to get Heineken 8)

22

Michael: I thought you were talking about building reuseable widgets. If so, it means you need to be able to “store” them somewhere int he Servoy Object Model, reference them, be able to place them on a form again etc. so, that basically is: a form… :)

Is there was some sort of (tabbed) container element that you could place on a form and then could place elements into, I’m sure you would also still want to be able to access the elements placed in the container element directly. So, that would call for a new part of structure in the SOM, that also needs to be accessible in scripting (forms.xxx.elements.containerElementName.???). And all that, while forms allready give you that ability.

What is the main reason you do not like to create an extra form? I assume it has something to do with creating an endless list of forms, which makes it difficult to maintain your solution afterward, or am I wrong? Maybe we should look into that area for a solution then…

Another thing I’m thinking about (allthough not sure if technically possible) would be the ability to use the grouping functionality that you currently have in Developer, but have the ability to assign the group a name, so it becomes an element that you could script against. Question then is what properties the group has. I guess at least visible, enabled and the location properties. Like I said: not possible if technically possible, but I could enquire if that would be helpfull.

Paul

23

Paul,

A few comments:

  1. Yes, it does seem at times that additional and what feels like extra forms are needed …

  2. I like the idea of a grouping functionality. Perhaps this is an extension of the tabpanel object.

  3. Perhaps a few additional methods would help. In my earlier comments in this thread I had mentioned the notion of “acquiringFocus” and “losingFocus” (this is not the same workflow condition as say the getTriggerxxx genre of methods).

I hear what you are saying and agree for the most part. For lack of better feedback to you it feels like something that one would almost need to brainstorm as a group (which is why a round of Heineken is probably called for!). Some of this I am processing intuitively … it is the sense I have during design/architecture when there is possibly another solution that needs consideration. That sense I have may end up being confirmed (yes, here is another idea!) or put aside (nope, the existing approach is the best).

I will continue to reflect on this topic and send you any more concrete ideas that come to mind.

Thanks, Michael