How many levels of inheritance can you have when creating new applications. I can't seem to get any more than 3.

A possible factor in using more levels of inheritance…

If you look at Sprezz's SENL article on promoted events (V1.7 or 1.8, I think) you'll see that window event processing goes searching through an extensive range of inherited event process possibilities. Also, no doubt, other procedure calls, etc. search inheritances.

Hence, I presume, the more inheritance levels, the more processing, the slower it all works.

No doubt the gurus will comment on this usefully and I look forward to reading what they have to say.

We have to set up lots of inheritance but from SYSPROG we have several generic apps (with pointer entities for common elements between them and/or use of SYSPROG) and then individual clients are the final third level where individual mods can be made (maybe with some pointer entities for elements shared by just a few users). You obviously have reasons for wanting more levels.

I recall that though the system was intended to allow for any number of inheritances, Cameron had said that beyond three levels one or other of the tools (RDK perhaps?) didnt work reliably. Sorry cant be sure about the specifics.

Richard Bright

Whats strange is that when I create the 4th level account is that level 3 seems to be ignored.

If I check @appid from level 4, it looks something like.

LEVEL4 @fm LEVEL2 @fm SYSPROG

If tried a number of combinations to create this but no joy.

Its only for development purposes so speed isn't a great issue. The client version is a maximum of 3 levels deep.

Maybe I'm creating it wrong, but it doesn't look like rocket science.

Any suggestions?

Paul

Taking up your point that speed isn't an issue as it's for development. In fact the deployed app at whatever level contains any entity at all levels. E.g. If MYPROG in LEVEL3 overrides MYPROG in SYSPROG, then they'll both be there in the deployed app. Hence it would seem the deployed system will scan through inheritance to get the right version and hence the more levels the more scanning.

Problem comes if one decides later that LEVEL3 doesn't need its override. If one deletes in SYSPROG then development copy fine but RDK doesn't detect deletion and one has to remember to get it (and its repository entries) deleted from the deployed copy. On a few occasions I've had some fun with this game!

Just some points of clarification:

In fact the deployed app at whatever level contains any entity at all levels. E.g. If MYPROG in LEVEL3 overrides MYPROG in SYSPROG, then they'll both be there in the deployed app. Hence it would seem the deployed system will scan through inheritance to get the right version and hence the more levels the more scanning.

Since locally stored components always take precendence over inherited components of the same name, I don't believe the system will scan for additional components once it detects a local version. That is, no speed hits in this situation.

Problem comes if one decides later that LEVEL3 doesn't need its override. If one deletes in SYSPROG then development copy fine but RDK doesn't detect deletion and one has to remember to get it (and its repository entries) deleted from the deployed copy. On a few occasions I've had some fun with this game!

I think you have the right idea but the wrong direction. LEVEL3 components will always launch no matter what you do to SYSPROG. However, SYSPROG components will only launch if you delete the LEVEL3 components. We to have been hit with the problem of deploying a SYSPROG stored procedure only to find out the the application already had a local version of the same stored procedure and consequently our version never was launched.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don

I cannot disagree with anything you say.

There are two aspects :-

1) Repository Components (windows, procedures, popoups, etc.). If a component is found at LEVEL4 then I am sure that the search stops there. If, however, the component is not overridden at all but is in SYSPROG then presumably the system will look at LEVEL4, LEVEL3, and LEVEL2 before concluding on sing the SYSPROG component. Thus I surmise, unless everything is locally overridden, more levels=more search=more time - even if not significantly so.

2) Event processing. Referral to SENL's item on this subject suggests the chain of searching for event handler procedure until a RETURN 0 is encountered, including searching various possibilities at each inheritance level. In many cases there will be just a generic event handler supplied by RTI (e.g. READ, WRITE, QBFNEXT, etc.). SENL suggests that the full search is only performed once in each circumstance per session, with the required chain being remembered for subsequent usage. I therefore conclude that the event processor must search all inheritance levels for each circumstance first time per session. Again more levels=more time - if only the once.

Perhaps, even if true, this isn't significant for the number of levels most people are likely to get to - that is, it seems, if they can get more than three levels to work.

Normally the window compiler does the event chain resolution for you, that's why you have to recompile windows when you add a promoted event.

But your points about speed are pretty much right - we have to admit to not having experimented beyond three layers as a rule.

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

Sprezz

Thanks for clarification.

Without digging out your SENL item, I'm relying on my memory (all few k of it!).

Indeed I recollect a comment about recompiling windows after adding promoted events. But you also described the monitor scanning all permutations and combinations of possible events until finding a RETURN 0 or exhausting the possibilities. Then I recollect a comment that, after the first such exercise in a session, the window learns and doesn't go through the contortions again. I understood this was when the window runs - but maybe it was the behaviour of the compiler.

Maybe the best thing is for me and any others interested in inheritance, promoted events and allied subjects to look again at your SENL article(s).

Richard, again you are correct . If you Return 1 you FORCE the runtime engine to traverse the event tree looking for promoted events. After the first such attempt it caches the ones it has successfully found and then only calls them subsequently!

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

There's one small point in all this that has been overlooked. This is only valid during development. When an application is deployed, the inheritance chain is flattened out, leaving just one level. So, you might have 4 or 5 in development, but your users will only have 1.

The Sprezzatura Group

[i]Celebrate CeBIT with Sprezz Local![/i]

View this thread on the forum...