miguelleeuwe
Programmer
a week ago or so, I stated to have found a bug in pb11 (think it might also happens in 12):
<i>
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.
</i>
I now found an exact way to reproduce it:
1) create a new userobject of type 'custom visual'
2) simply save with no code whatsoever with name 'u_object'
3) create another new userobject of type custom visual' and put a dw-control on top of it: dw_1. add another control: userobject, and choose the previously saved 'u_object': uo_1 and put some code in the rbuttondown event of uo_1: (for example: dw_1.setfocus() )
4) save the custom visual userobject from 3) as 'u_done' in a library: you now've got a "u_done" object, containing a dw_1 control and a userobject control uo_1 with little code in it.
5) create a new userobject of type 'custom visual' and DO NOT save it yet:
6) open the previously saved object: u_done, rightmouse click on the uo_1-control and choose copy.
7) select the new ('untitled') custom visual userobject from the 'window menu' and paste the copied control from 'u_done'. (choose the 'edit, paste control' menu or simply do a 'Ctrl+V' to paste the copied control).
(now you'll have a userobject control 'uo_1' on top of your new custom visual one, which hasn't been saved yet.
8) save the object by keycombination ctrl+S and choose a library and name for the new object: for example 'u_new'.
9) the object logically won't save, since the copied control has a 'dw_1.setfocus()' script and there's no dw_1 on the new object.
10) so far so good, but .... check the eventlist of the uo_1 control: you'll see a new event called 'destroy' with the constructor event coded as follows: "call u_control::destroy"
Now this is no good! this kind of code is present in the source code, but should never appear as an event (there is another event called 'destructor' to not make any confusion, which is perfectly legal, but is not the same as 'destroy' event).
If you delete the 'call u_control::destroy' script and try to save, pb 11 will GPF or might save, but when opening the object again, you'll see your script has not been deleted.
if you first comment the code, before saving, then save and uncomment the code, this spontaneous event 'destroy' does not appear.
It's like powerbuilder fails to ubicate the destroy source code in the right place when compilation fails at saving after copying a (custom visual user-)object.
Workaround:
- comment all the code, save and then uncomment and fix the errors.
- simply delete the 'destroy' event from your eventlist of the control
- or simply don't copy controls this way.
Hope it helps anyone around there. Anyway this kind of code has been around in our application for some time and we never noticed any erroneous behaviour.
I'm still checking out tab controls with tabpages: they also seem to have a comparable erroneous behaviour: 'destroy' event and also 'create' events are appearing in some of our object. Still have to figure out if this is really for a 100% an error or they have to be there, but I'm really declined to think it's the same error.
Miguel
regards,
Miguel L.
<i>
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.
</i>
I now found an exact way to reproduce it:
1) create a new userobject of type 'custom visual'
2) simply save with no code whatsoever with name 'u_object'
3) create another new userobject of type custom visual' and put a dw-control on top of it: dw_1. add another control: userobject, and choose the previously saved 'u_object': uo_1 and put some code in the rbuttondown event of uo_1: (for example: dw_1.setfocus() )
4) save the custom visual userobject from 3) as 'u_done' in a library: you now've got a "u_done" object, containing a dw_1 control and a userobject control uo_1 with little code in it.
5) create a new userobject of type 'custom visual' and DO NOT save it yet:
6) open the previously saved object: u_done, rightmouse click on the uo_1-control and choose copy.
7) select the new ('untitled') custom visual userobject from the 'window menu' and paste the copied control from 'u_done'. (choose the 'edit, paste control' menu or simply do a 'Ctrl+V' to paste the copied control).
(now you'll have a userobject control 'uo_1' on top of your new custom visual one, which hasn't been saved yet.
8) save the object by keycombination ctrl+S and choose a library and name for the new object: for example 'u_new'.
9) the object logically won't save, since the copied control has a 'dw_1.setfocus()' script and there's no dw_1 on the new object.
10) so far so good, but .... check the eventlist of the uo_1 control: you'll see a new event called 'destroy' with the constructor event coded as follows: "call u_control::destroy"
Now this is no good! this kind of code is present in the source code, but should never appear as an event (there is another event called 'destructor' to not make any confusion, which is perfectly legal, but is not the same as 'destroy' event).
If you delete the 'call u_control::destroy' script and try to save, pb 11 will GPF or might save, but when opening the object again, you'll see your script has not been deleted.
if you first comment the code, before saving, then save and uncomment the code, this spontaneous event 'destroy' does not appear.
It's like powerbuilder fails to ubicate the destroy source code in the right place when compilation fails at saving after copying a (custom visual user-)object.
Workaround:
- comment all the code, save and then uncomment and fix the errors.
- simply delete the 'destroy' event from your eventlist of the control
- or simply don't copy controls this way.
Hope it helps anyone around there. Anyway this kind of code has been around in our application for some time and we never noticed any erroneous behaviour.
I'm still checking out tab controls with tabpages: they also seem to have a comparable erroneous behaviour: 'destroy' event and also 'create' events are appearing in some of our object. Still have to figure out if this is really for a 100% an error or they have to be there, but I'm really declined to think it's the same error.
Miguel
regards,
Miguel L.
