Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 1 Jahr, 3 Monaten
Letzter Beitrag:
vor 1 Jahr, 3 Monaten
Beteiligte Autoren:
Steve Hodgman

Annoying Change in Behaviour WD19 => WD20

Startbeitrag von Steve Hodgman am 27.04.2016 00:08

G'day All,
I realise that I am a little slow off the mark in converting to V20 as I did not want to be held up by differences in behaviour in the new version. Well, I have found one that might seem obscure but has caused me a little grief so I thought I would share what I have found.

I use a lot of classes. I make the members PRIVATE and access them via properties.
I also have members that are dynamic object definitions that can be assigned to "point" to existing instantiated objects. I declare them as say:
m_pclMyPtr is ctMyclass dynamic

To create the property I use the "Right click" on the member in the project explorer. This generates the "Getter" and "Setter" procedures.
(N.B. In V19, as I created them they would appear in the explorer property list. That does not happen in V20. They do not show)

This process creates the Procedure definitions like:

PROCEDURE p_pclMyPtr(clValue ) : ctMyClass // Getter

PROCEDURE p_pclMyPtr(clValue is ctMyClass) // Setter

Now, up to V19 I could assign a Null value to the member via the class property Setter, defined above. e.g.
clMyObject.p_pclMyPtr = Null

In V20, if I assign a value of Null to the property as defined above then this does not happen. What happens is that the member is assigned an "Empty" class container. I say empty because the class has not even been instantiated i.e. the Constructor has NOT run. Seems like the class is being treated like a structure.

However, if I remove the type specification in the Procedure declaration for the Setter procedure then the member DOES get assigned to Null. i.e. the Setter definition becomes

PROCEDURE p_pclMyPtr(clValue) // Setter

This behaviour has been introduced in V20. Currently I am reviewing my code to confirm I have found all instances where this affects me.

I have no idea why PC Soft have done this. Null is a valid value for a dynamic object as far as I know. The difficult thing is that the member ends up an invalid value. Not Good!

So far, this is the only substantive issue I have had in upgrading to V20. Pretty good really.
I am guessing that this behaviour will also carry over to V21.
Steve H


Further testing shows that if a procedure header specifies a class object as an optional parameter with a default of Null then this Null does seem to get passed into the procedure. i.e.

PROCEDURE SetToNull(pclARG_Value is ctDemoClass = Null)

Calling this procedure with no parameter will result in the argument pclARG_Value having the value of Null

That will save a lot of changes for me.
Steve H

von Steve Hodgman - am 27.04.2016 01:38
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.