máximul length for object names

[miguelleeuwe]

Hi there,

I've solved a recent problem with an object that - when trying to show the script of a control with 'very long' name - GPF'ed and closed down PB 11 ( 12 has the same problem).

The problem was that there was another object with an almost equal name. Reducing the object name, everything started to work fine.

Even though powerbuilder objects can have a long name (128 chars?), it seems that internally PB 11 doesn't permit/use the same length.
When you export an object with very long name, also, the filename is not the complete length (seems to be 40 chars + '.sru')!

Any info about how to avoid this (using shorter names), does anyone know the exact máximum length to work without problems????

tIA,
Miguel Leeuwe




regards,
Miguel L.

 

[mbalent]

The name of the object is contained within the export file. The name of the file itself seems to be irrelevant (except for the extension). I have not heard of this before.

Matt

"Nature forges everything on the anvil of time"

http://www.anvil-of-time.com

 

[miguelleeuwe]

Hi Matt, thanks for the answer.

The problem is that a certain object, inherited from another one, with long name (and existing other objects with almost same names), provoces a GPF when trying to show the script of another object that has it pasted.

I've seen this happen before at another company, with dw's also using pb 11 and very long names. Can't be saved. when reducing name length (exported code) everything starts to work).

If your interested I´ll send you the exported code (if I manage to reduce dependencies to only those three objects), so you can see for yourself.

Best would be an e-mail address to send it to, but if you want I´ll post it on a web-site.

let me first try to reproduce the case.

Another interesting "fault" I've been struggling with yesterday is the 'spontaneous' appearance of 'destroy' objects. The code inside shows "call controlname::destroy ( )" (white space important if you want to do a search in exported code. No good the pb-normal-search.). When checking the ancestor event I found 'end on'. I believe that this code corruption is caused by copying one control from one userobject and pasting it in another one.

In both cases, the first parent of all objects seems to have a 'cyclic' reference: it declares local variables of it's own type.
The solution to this last problem is easy: simply delete the 'destroy' (is not 'destructor' !!) events.


Thanks,
Miguel


regards,
Miguel L.