Hide Tabs in a SmartFolder?

I would like to have a combobox that selects which tabs are displayed. Possible?

Multiple page sources don't seem to be possible. Are there multiple ways to crack this nut?

I'm a SmartObject newb, so take it easy on me.
 

RealHeavyDude

Well-Known Member
What Progress/OpenEdge version you are talking about?
Are you talking about ADM1 or ADM2 or even Dynamics?

Either way, AFAIK, to hide folder pages which have already been realized during initialization of the container is not an easy task. I was successfully able to avoid such a requirement for aforementioned reasons. I am not sure what it is you're trying to achieve. Is enabling / disabling particular folder pages depending on some rules not sufficient for you?

Regards, RealHeavyDude.
 
Greetings,

As far as I am aware, it is NOT possible with Progress.
The widgets have to be instantiated through the OS.ve fun playing
Sorry, U may be able to set an attribute on the fly, something like :visible, :sensitive though the OS requires the objects to be instantiated first. Possibly having a control procedure to set widget status?
Have fun playing.
 

RealHeavyDude

Well-Known Member
You do realize that the smart folder in ADM1/ADM2 are pure 4GL widgets and therefore nobody needs to dig down as deep as into the OS to fiddle with 'em?

Regards, RealHeavyDude.
 
Greetings,
Obviously the tab folders are 4GL, though how does the 4GL display them? Erm could it be the Operating System - the 4GL creates the tabs which are instantiated by the Operating System.
The widgets have to be instantiated before you can set any attributes at run time, otherwise the widgets won`t exist
 
We're 10.1C here, so ADM2. Didn't think the version would make a difference in any suggestions.

Basically, building a remote version in Progress of a screen in another system. We really don't use tabs in our current system, so there is not much to imitate and implementation is wide open.

The user populates any of thirty fields and a call to send that data to the external system is fired upon save. There is nothing even stored in a Progress DB, so I really just need the tabs to emulate the user interface of the other system so the users will feel at home (10 fields per tab).

Further, since this whole "thirty fields from another system" will be expanded soon and I'll have four different sets of thirty to deal with, I thought I might build it all now and have a combobox select which set of fields to edit. Default and grey out the combobox for cases where only one type is needed, enable the combobox when it's appropriate. The combobox also would serve as a handy label for the fields, letting the user know what they're editing (as labels on the individual fields can be variable).

I had a hot lead with editing the "adm-create-objects" to conditionally create the objects I wanted, but it's too hard fighting the auto-overwriting tendancies of AppBuilder, and there is no way to get this behavior "officially" (it seems). I didn't even get to the point of trying to re-run "adm-create-objects" ON VALUE-CHANGED of my combobox, so I don't even know if if would let me.

I was hoping there was a way I could just make 12 tabs and only show 3 at a time based on the status of the combobox.
 

RealHeavyDude

Well-Known Member
You should never, never, never edit the adm-create-objects procedure of a container as it get's automatically updated whenever you drop smart objects onto the container. Instead you could utilize the postCreateObjects procedure which fires as soon as you code it into the container (assuming we're talking about a .w file). In this postCreateObjects procedure you could do the same (running createObject ...) like in adm-create-objcts but conditionally. When you're done you should run initializeObject to reflect the changes you did on the objects which are on the container.

Does that make sense to you?

Regards, RealHeavyDude.
 

RealHeavyDude

Well-Known Member
Ooops - I forgot: Mentioning your ADM1/ADM2 version is essential information as some of the functionality might not be there below a certain version of ADM2. ADM1 is a completely different story. From the result you get they may look like almost the same, but under the covers they are as different as a horse-drawn carriage and (since the ADM2 is considered old too), let's say a Ford T-model.

By the way: Running the createObjects sequence (which will run adm-create-objects as the first thing) in a smart object does not make any sense at all. Depending on what you code into a customization of the process (postCreateObjects) it may or may not make sense too.

Regards, RealHeavyDude.
 
I am barely hanging in this conversation, because of the my SmartObject newb-ness. Things like knowing whether or not decisions make sense in SmartObject world are beyond me at this juncture.

However, in January, you helped someone with a similar question (which I just found). http://www.progresstalk.com/showthread.php?116612-Delete-page-in-a-second-smart-folder So, hiding/removing tabs can't be done. Period.

But what about changing the tab label on the fly? I need tabs. I can envision squeezing 12 tabs of fields into 3 tabs and hiding what I don't need based on the combobox selection, but unless I can change the tab labels, this solution moves from clunky to impossible.

Or am I fated to make 4 clones of this screen and have a clunky interface to get between them?
 

RealHeavyDude

Well-Known Member
Sorry for the "philosophic" discussion - I just found it interesting when talking about the functionality of a framework like the ADM2 to mess with widgets on the OS level.

Furthermore, it's hard for me to anticipate what you know and what you don't know. Especially when a very specific question about specific functionality is asked.

So, why don't we just step back for a moment and look at some basics - if you bare with me:

The concept of smart objects in the ADM2 is that they are persistent procedures and you "glue" them together in a container in linking them with each other. When you link 'em what happens in the background is, that they get subscribed to each other for certain events. So when a object has a new state or functionality from another object is needed it just publishes something.

Back to the container. The container can't do much more than contain other smart objects. You might have realized that the AppBuilder won't let you drop widgets onto a container ( if it does it's already customized ). You can place the smart objects on different pages of the container and the container class contains functionality to switch between pages. There is one exception to that in that the objects which reside on page zero are always shown. Next you need another smart object to control the paging of the container - for example a smart folder. That's all it does - it is a means to control the paging ( which essentially is hiding and viewing container pages ). The smart folder itself is an object which does not have the functionality to hide folder tabs and labels build into it. Therefore if you need that functionality you either need to build your own object class that controls the paging of a container or you would need to customize the existing smart folder class to introduce that functionality into it. While both alternatives are valuable you need lot's of experience to achieve something like that.

It's like with all frameworks: You can either work with 'em or work against 'em. You'll probably wind up full of frustration giving up when you choose the latter option. But how are you to know? That's one of the basic problems of using a framework - it's not about syntax, it's about functionality built into the framework. This is absolutely true for the ADM2. You need an understanding how the ADM2 works in order to successfully develop an application with it - and there is hardly any documentation available other than the source code itself. Therefore, while it's possible to get into it yourself I recommend you to get some sort of training or starting point from an experienced ADM2 developer to save you a lot of time.

Back to your problem: The container provides several internal procedures and functions which control the paging. Theses are selectPage, changePage, viewPage, hidePage - you just need to call 'em. Whether you use the smart folder which will automatically call these when you click on the folder tabs or you do it manually is basically up to you. But, if I were you, I would build my own "paging source" object to control that. AFAIK ( I have no ADM2 development environment at hand right now ) the instance properties of the smart folder allows you to set the visualization to a combo-box style type ...

I hope you don't get mad at me and get the point. As English is not my first language and did not really get what it is you are trying to achieve with your last answer.

Regards, RealHeavyDude.
 
Facilitate / impression

Greetings

As previously mentioned this is not really possible with the 4GL we all love so much.
However this could be realized with a little thinkinge to present the functionality.
You are using SmartObjects so U can have as many instances as U like to give the impression the application is performing as U require. Nobody needs to look under the hud to see the illusion.

Have a tab folder on page 0 as normal, setting UR start page to page 1. Placing the appropriate smart objects on the appropraite pages. Nobody needs to know the page looked at when selected. U can have dummy pages with only the required smart objects on. U can even drop a combo box into a smart object have that smart object on the required page. Setting the functionality of the combo box to change to page ?? on selected item
Good look
BFN
 
Top