1. Brad Mettee
  2. PowerBuilder
  3. Saturday, 29 July 2017 15:22 PM UTC

There is some internal functions that would be a great deal of help if they were added, and some others that would be nice to have docs for.

Existing - The rt_dbg_* functions in pbvm*.dll are a powerful debugging tool when /pbdebug is too slow to use. Is there any way we can get some basic documentation for this group of functions? 

Desirable:

  • Being able to turn off the rt_dbg console window. Right now, once you turn it on in the dev env, closing it kills the PB dev environment with no prompts. Same happens with a running EXE, app closes with no events firing. Even being able to get the handle of the console would allow us to change it's visible state with WINAPI calls
  • Make PB forget where a DW came from. When dealing with nested datawindows, if you need to modify one (sort order, additional objects, removing objects), there's no way to load it from your exe/pbd into a string, change it, then save it back out someplace for use because PB now remembers where the DW was originally and won't load the modified version that's now in a .pbl, even if it's earlier in the library list. We've managed to work around this issue by creating a separate report modifier exe, and using it to save the modified object into a pbl that the main app knows about, but it's difficult to set up and "teach" the report modifier what it needs to do based on a simple command line.

Anyone else have ideas or requests for access to PB internals? I'm sure there are other ideas out there that would make PB development more flexible, or debugging easier.

Accepted Answer
Julie Jiang @Appeon Accepted Answer Pending Moderation
  1. Wednesday, 23 August 2017 08:15 AM UTC
  2. PowerBuilder
  3. # Permalink

Thank you Brad. These are interesting ideas.  I have noted it down and will pass to our engineering team for their analysis.  Right now they are too much occupied with the development work of the next version.  Maybe they can find out something when they get some free time. 

Best regards,

Julie

Comment
  1. Miguel Leeuwee
  2. Thursday, 7 September 2017 01:32 AM UTC
Hi Julie,



For years, "__get_attribute()" has been an undocumented function of datawindow objects. It's very useful to dynamically create a dwo from a string with the column name.



Could this undocumented function become a "documented" one, with gaurantee it won't be deprecated in a future?



This is (as an example) what I do to see if a columnName really exists on a dw:



 



function f_create_dw_object:



parameters:



datawindow    adw



string    as_colname



dwobject    adwo_created



////////////////////////////////// code //////////////////////



if not isvalid(adw.object) then



    return false // assigned dataobject is a non existing datawindow



end if



 



try



    adwo_created = adw.object.__get_attribute(as_colname, false)



catch (DWRuntimeError rte)



    return FALSE



end try



 



if isvalid(adwo_created) then



    return TRUE



end if



 



return FALSE



 



 



Thank you!



Miguel Leeuwe

  1. Helpful
There are no comments made yet.
Miguel Leeuwee Accepted Answer Pending Moderation
  1. Thursday, 7 September 2017 01:36 AM UTC
  2. PowerBuilder
  3. # 1

Great idea, I've got one too (until now undocumented but widely used by the pb developers I think):

__get_attribute(ls_columnName, boolean) to creata a dwobject dynamically from a string 

See my answer to Julie.

Comment
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.