Container tabpanel

[Riccardino]

Sounds like we'll have to reserve a whole night at the bar at 'world to talk just about tab-panels and containers! Containers containing drinks will be excluded from the talks.

Hei: those are my favorites!

[Riccardino]

For instance, on your "before" graphic, how about containing some of the major "elements " (like portals) within a tab index or a tabless tab panel (with embedded forms) to help provide a seamless switch and visually pleasing movement back and forth (from "before" to "after")? I personally much prefer the use of a form within a tabpanel as compared to a portal.

For e.g.:

1) Tab panel to contain the "Patient Profile or Statistics" area
2) Tabpanels to contain the 4 or 5 forms - these are contained within 1)

I am just getting ready to post this and I see Jan has already commented as well!

As I told Jan, I know it would solve the problem (btw, the picture is only an example, actually of a very old application, born when tabless panels didn't exist, back in Servoy 1.0 times).
The point is: if I need a form to place a portal in it, I'll use a form, which gives me a lot more freedom.
But since portals are useful for avoiding "service only" forms, I was wondering if there's a way to place them more efficiently without losing their main peculiarity (which is: "no forms needed")

[Michael Mooney]

Ric,

You bet! Works very well. Steps are:

1. Make sure the relationships between the tables are 100%
2. Get a form looking the way you want (in this case, like a portal). Use a List or Table view
3. Add a tabpanel to your main form. When you want to add another form to an existing tabpanel (more than one "index" or "tab") make sure you click on the tabpanel first and then the tabpanel icon. Select whether you want a Related or Unrelated tab.

That's it!

Works very well.

ps - a quick edit ( I saw your last post and realized you probably already are well aware of the above). I see your point on the portals as a handy service-only object.

Michael

[Riccardino]

Works very well.

Michael

Thanks, Michael

if I remember well, I used a couple of them, during the last 4 years

[Riccardino]

ps - a quick edit ( I saw your last post and realized you probably already are well aware of the above). I see your point on the portals as a handy service-only object.

Michael

Don't worry: enthusiasm is always nice to see and I appreciate your help.

You can find me at the bar, at ServoyWorld ;)

[Michael Mooney]

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

[pbakker]

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

[Michael Mooney]

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