Hi Jasper,

I still have a need for trees for 2/3 level displays where it makes sense,
(not to show all 3000 customers per plant as a tree).

One option is to abuse some triggers where you can check occurences in all levels in one go.

Assume we have 3 levels in our organisation: Company, Country, Plant

For detailed reporting I want to choose in all 3 levels:

If I request the report for a complete country,
I still may request details for plant P4.

If I see there is a report for the complete country, I may not need to choose their plants.

Success, Uli

P.S. or have I misunderstood your "one-entity" tree ?

If this would allow for the stepped hitlist in a tree widget. Then I'm for it. The tree doesn't provide for data entry, so it's generally relatively simple to build against data, the only thing missing is the thing available form the triggers window where the tree can react to the scroll bar and populate more data as the bar is dragged down.

Do it Jasper !

Despite samples and everything the current tree widget is really difficult to get working the first few times you try it.

I want to  paint three enitities within each other for example CITY, STREET and HOUSE.

In the CITY enitity I paint the field name.CITY.
In the STREET entity I paint the field name.STREET.
In the HOUSE enitity I paint the field number.HOUSE

I then define the grid widget on the outer entity.

And then it should work.

Keep it as simple as possible for us developers, productivity is one of the core values of Uniface !

I will try to push this on the list for new functionality. A prototype already showed that this is worth the effort. Fast and easy to use. Since I now see that 4GL developers are eager to get one it convinces me to take action. Jasper

Dragging the scrollbar should initiate a fetch from the database in an entity level tree. Just as is the case in the GridWidget.

It actually means that you can populate the tree without writing 4GL code. Just by using the stepped hitlist mechanism as is available.

Kind regards,

Jasper

This is what I had in mind. Just being able to display an entiity with an inner entity etc in a tree. And using by this the benefits of the hitlist. Using creocc and remocc to insert/remove items etc. Current tree requires a lot of programming to do so and does not make active use of the hitlist.

Jasper

Hi Jasper (and others),

this idea is just great, and I am for such a tree, in any case. Nowadays, we just build a tree dynamicaly, with lot of programming (and tree is build in whole at once). This entity level tree, with inner entities and all these hitlist/creocc/remocc/discard etc etc functions, would be of real use. At least for us.

Zdenek

Hi all,

my 2 cents:

pro: 

• stepped hitlist 
• mechanism of internal data formatting can be hidden within uniface.

contra (or at least questionable): 

•  Can the techniques be transported into a web-environment too? (otherwise we need to reinvent the hidden techniques anyway!)
•  Possible side effects needs, as known e.g. from the gridwidget:
  •   RTL support!
  •   country specific formatting? (and sorting)
  •   Holding column width in memory or in registry,
  •   memory problems ...etc.

• stepped hitlist for complex data structures?

In my opinion, the job will not be easy, to get all aspects into a entity-level-tree.
If all this can be taken into account, welcome! Especially Web and RTL are important themes for us.
 

W.

Some answers,

• The idea is to have the tree as a property of the entity. If there will be a tree on the web than this should follow the same idea's.
• RTL support. Any implementation will use the standard window Systree32 control. I guess this control supports any language.
• Country specific formatting is something new in 9.4 and will be inherited by any control.
• Holding column with in the registry. I think not applicable but I can be wrong
• Hmm, memory problems. Compared to the grid, the tree does not really take a lot of memory holding an entity. Grid cells are rather complex objects compared to a tree node.
• Stepped hitlist for complex data structures. I guess you mean entities with inner entities etc? That would be my prefered option. A tree which spans multiple entities. For instance cusomer->order.

And true, this job is complex but may take the burden of the 4GL developer's shoulder.

Jasper