Bhavbhuti,

If the classes have designtime containership and you are wanting to change the contained classes, then you are stuck. You can make direct changes to the contained class, which causes work should the framework ever be updated. You just have to weigh the amount of work between changing the framework once in a great while, or having to change things in every app.

If you decide to make the changes in every app, you can write a builder that would start your new app project and then make the changes. For example your "splash" builder might look like:

create class appxsplash of appclasslib as splash from frameworkclasslib nowait
aselobj( laX )
oSplash = lax[1]
with oSplash
   .Picture = getpict()
   .AddObject( "lblx1", "SomeLabelClass" )
   with .lblX1
      .Top = 200
      .Left = 50
   endwith
endwith

Your appbuilder could just sequentially call a set of individual builders.

If you wanted to get fancy you could in fact build the builder by taking an existing altered splash form, and compare it to the base splash form looking for the differences and write that out as the first cut of your splash builder.

>>That's the main reason for creating your own layer of classes. So that you can fix/change the classes to suit your requirements and still be able to recieve updates to the framework classlibs.
>
>But the a-level is supposed to be the framework topmost level with my own customized classes in my own classlibs at i-level and my own subclasses at a-level