Subscribe via RSS
Toggle Submenu
  1. Categories
  2. Recent
  3. Tags
View Replies (5)

Resolved Any alternate/workaround for Classdefinition Object

  1. How-to
0
Votes
Undo
  1. shoaib siddiqui
    shoaib siddiqui
  2. PowerServer Mobile (Obsolete)
  3. Thursday, 24 January 2019 15:10 PM UTC

 

Converting a huge client/Server app to web and mobile app, module by module, I know I have to through a lot.

 

in our code, frequently required to know the ancestor class name.. ie

 

///

ClassDefinition cd_windef

do
cd_windef = FindClassDefinition(as_classname)
if cd_windef.ancestor.name = "w_base" then
exit
else
cd_windef = FindClassDefinition(cd_windef.ancestor.name)
end if

loop while (cd_windef.ancestor.name="")

 

RETURN cd_windef.ancestor.name

//

 

Is there any list of Unsupported Object/Function calls and their workaround somewhere, I went through PowerServer help and still learning.

Thanks.

Deployment wizard error 12031 ?
Voice Recognition function on IOS by PowerServer M...
Responses (5)
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 24 January 2019 22:32 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 1

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

Comment
There are no comments made yet.
Chris Pollach @Appeon
Chris Pollach @Appeon Accepted Answer Pending Moderation
  1. Thursday, 24 January 2019 22:28 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 2

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

 

 

 

 

Comment
shoaib siddiqui
  1. shoaib siddiqui
  2. Friday, 25 January 2019 14:08 PM UTC
Thanks Chris,

Our app is heavily utilizing three to four levels of inheritance in business objects. some modules need to know where a specific object is sitting on and what level of inheritance is used, then based on location or object name, business logic has to take different rout of code execution or workflow changes based on object.

for example this custom visual object function RETURN which business objects

to be set to use:





u_dw_maint ldw_maint

w_maint_base lw_maint_base

w_base lw_3tier_base

string ls_class

ClassDefinition lcd_window



lcd_window = iw_parent.ClassDefinition

ls_class = lcd_window.name

SetNull(ldw_maint)

do while isNull(ldw_maint) and ls_class "window"

lcd_window = lcd_window.Ancestor

ls_class = lcd_window.name

choose case ls_class

case "w_maint_base"

lw_maint_base = iw_parent

ldw_maint = lw_maint_base.idw_maint

case "w_base"

lw_3tier_base = iw_parent

ldw_maint = lw_3tier_base.idw_maint

end choose

loop



return ldw_maint



  1. Helpful
Chris Pollach @Appeon
  1. Chris Pollach @Appeon
  2. Friday, 25 January 2019 17:40 PM UTC
Thanks Shoaib for that information. That is a very interesting App design for sure. I have never seen it done that way before in introspecting ancestors to determine the business flow.

Unfortunately, that approach will now work in PowerServer based Apps. My suggestion at this time would be to open a support ticket ( https://www.appeon.com/standardsupport ) for this issue and then mark it as an "enhancement" request for PowerServer. However, this would not help you in the short-term. :-(
  1. Helpful
shoaib siddiqui
  1. shoaib siddiqui
  2. Friday, 25 January 2019 18:41 PM UTC
Thanks Chris, I'm going with window function approach in all Ancestor windows classes to return string (object name) and go from there.
  1. Helpful
There are no comments made yet.
John Fauss
John Fauss Accepted Answer Pending Moderation
  1. Thursday, 24 January 2019 19:47 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 3

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.

Comment
There are no comments made yet.
shoaib siddiqui
shoaib siddiqui Accepted Answer Pending Moderation
  1. Thursday, 24 January 2019 16:28 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 4

  

 

Comment
There are no comments made yet.
mike S
mike S Accepted Answer Pending Moderation
  1. Thursday, 24 January 2019 15:56 PM UTC
  2. PowerServer Mobile (Obsolete)
  3. # 5

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

Comment
shoaib siddiqui
  1. shoaib siddiqui
  2. Thursday, 24 January 2019 18:06 PM UTC
I wanted to know the ClassName of the window
  1. Helpful
mike S
  1. mike S
  2. Thursday, 24 January 2019 18:34 PM UTC
yes, but what are you doing with the class name?



if you are looking to do some specific processing based on the window being inherited from a specific window, then you design a work around.

  1. Helpful
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.
We use cookies which are necessary for the proper functioning of our websites. We also use cookies to analyze our traffic, improve your experience and provide social media features. If you continue to use this site, you consent to our use of cookies.