if you are asking for a workaround to finding out the ancestor class of an window:

you can use events to figure out what the ancestor class of a window (or anything that supports events) is from.

also works if you are passing around references of windows as parameters 

so add event 'ue_iAmFromBaseWindowClass' to your w_base.

in code you trigger the event to see if is there:

if lw_window.triggerevent('ue_iAmFromBaseWindowClass') = 1 then

//the event is there

else

//the event is not on lw_window

end if

If all I wanted was the name of the base class window, I would create a protected or public object function in the base window called of_ancestorclassname(), no arguments, returns string. In the function I'd code one line:

  Return "-name of ancestor window class here-"

Invoke this function from any descendant window.

Don't use the ClassName() PowerScript function, as it will return the name of the descendant window instead of the ancestor.

Hi Shoaib;

  This is a very interesting question indeed. First of all no - the "ClassName" method is not supported in PowerServer.

  More importantly though, what is your App trying to do with this ancestor information? Personally, I do not think that any class should be sensitive to the inheritance structure above it. You should be able to add or subtract ancestors without say "concrete" objects knowing or even caring if your overall framework design is correct.

  The purpose of these commands was introduced by PowerSoft way back when before we had the "Application Profiling" feature. The main reason was to allow any App to introspect itself at run-time in order to collect statistics on an object class and its ancestors for performance gathering. For example instantiation over-head - which was very important in PB Apps before PB v8 (where Sybase rewrote the "Class Loader".

  You can always bypass the code if its not useful in a PowerServer App by wrapping the functionality around a run-time environment check, like:

• IF  "PB" then
•     ClassDefinition()
• else
•     // Perform PS code variation
• END IF

Looking forward to knowing your App's rational for this.

Regards ... Chris

Hi Mike;

  FWIW: You would need to check the User Event's in reverse order from Concrete => Extension (there could be many) => Base => System Class because all the higher level UE's would be present at the concrete level as UE's are "public".

  Again the danger of this approach is the addition or subtraction of ancestors - especially in the Extension layer where there could be many.

An interesting idea though.

Regards ... Chris