WSTRING variable vs. WSTRING Property

[Knuth Konrad]

I'm a bit uncertain as this is how it's supposed to work, I'm doing something wrong here or if it's something the compiler is supposed to handle?

Compiler: PB/WIN 10.04

Given the following code:

Class CMYClass
   Interface IMYInterface
      Inherit Dual

        Instance mwsKey As WString

      ' *** Property Key
      Property Get Key() As WString
         Property = mwsKey
      End Property
      Property Set Key(ByVal wsValue As WString)
         mwsKey = wsValue
      End Property
'------------------------------------------------------------------------------

      Method ToVariant() As Variant

         ' Results in          Error 595:  Object return type required
         'Method = Me.Key

         ' Does work
         Method = mwsKey

         ' Results in          Error 595:  Object return type required
         Local vnt As Variant
         Let vnt = Me.Key

         ' Does work
         Let vnt = UCode$(Me.Key)

        End Method
'------------------------------------------------------------------------------

    End Interface
End Class

So why is a property's WSTRING return value different from a variable's or UCode$ one?

On a related note: I'd like to see a PB CVnt() function (~the opposite of VARIANT#/VARIANT$/VARIANT$$), similar to the other Cxxx() conversion functions.

[Michael Mattias]

So why is a property's WSTRING return value different from a variable's or UCode$ one?

I'm actually not sure it is different because I don't see the code used to make this difference determination. (Display code? String comparison code?)

But .... Maybe the WSTRING can be different because of changes in the code page specified in the UCODE$() call.

However .....maybe any differences are because you seem to be ignoring the help file..

This version of PowerBASIC handles all conversions between ANSI strings and UNICODE strings automatically. For example:

MyWideString$$ = MyAnsiString$

In this case, the ANSI characters are transparently converted to WIDE UNICODE characters when they are stored in MyWideString$. You should not insert a UCODE$ function here [Bold mine MCM]

Basically you are forcing a conversion of something the compliler has already converted.

I'd like to see a PB CVnt() function (~the opposite of VARIANT#/VARIANT$/VARIANT$$),

????
What's wrong with

 VariantVar =   (variable or inline value)  [AS TYPE]

[Knuth Konrad]

I'm actually not sure it is different because I don't see the code used to make this difference determination. (Display code? String comparison code?)

But .... Maybe the WSTRING can be different because of changes in the code page specified in the UCODE$() call.

However .....maybe any differences are because you seem to be ignoring the help file..

Well, that's what I tried (not using UCode$, which was just an example of what's also not working as I expected it). My main point/discovery was that a Property () As WSTRING seems to act different than an ordinary variable As WSTRING, so ignore the UCode$() example for the time being. It's just that I discovered it along the way of working around what I thought should work also, and is the way other object-orientated languages do in fact operate:

' [b]Results in          Error 595:  Object return type required[/b]
Method = Me.Key

' [b]Does work[/b]
Method = mwsKey

????
What's wrong with

VariantVar = (variable or inline value) [AS TYPE]

It doesn't work with a property, that's "wrong". Not wrong, but not supported. See, I'm trying to use objects "the object way", which implies using an object's properties. If I need to use the instance variables to manipulate a property's values within a class, that somehow defeats the purpose of a property. So I'm wondering if that's actually intended or if I'm doing something wrong?

[Stuart McLachlan]

It doesn't work with a property, that's "wrong". Not wrong, but not supported. See, I'm trying to use objects "the object way", which implies using an object's properties. If I need to use the instance variables to manipulate a property's values within a class, that somehow defeats the purpose of a property. So I'm wondering if that's actually intended or if I'm doing something wrong?

Help does say that Variants "use is limited to that of parameter passing ... PowerBASIC limits their use to data storage and parameters only. You may assign a numeric value, a string value, or even an entire array to a Variant.." Guess that means that you can't assign an object property directly but you could do something like:

 Method ToVariant() As Variant
Local s as WString
s = Me.Key
Method = s

[Michael Mattias]

Your code not compiling because the method is defined to return a VARIANT so you can't say "Method = <wstring>"

I'd probably redefine the method to return a WSTRING, since that is what it is anyway.

[Stuart McLachlan]

Your code not compiling because the method is defined to return a VARIANT so you can't say "Method = <wstring>"

I'd probably redefine the method to return a WSTRING, since that is what it is anyway.

Doesn't that rather defeat the purpose of a method called "ToVariant" ?

[Michael Mattias]

Doesn't that rather defeat the purpose of a method called "ToVariant" ?

I guess it would except I was only seeing snippets.

But for the life of me I don't know why I'd want to return a variant of a data item which is a WSTRING when I could just assign it (Post #3)

Alternately, you could just use the WinAPI functions provided to handle variants. (And in this case strings).

Besides, you are going to have some scope issues with variants anyway.

MCM

[Knuth Konrad]

Your code not compiling because the method is defined to return a VARIANT so you can't say "Method = <wstring>"

Obviously posted without testing that premise, because it works just fine:

#Compile Exe
#Dim All

Function PBMain () As Long

   Local vnt As Variant
   Local o As IMYInterface

   Let o = Class "CMYClass"

   vnt = o.ToVariant
   Con.StdOut "vnt: " & Variant$$(vnt)


End Function

Class CMYClass

   Instance mwsKey As WString

'------------------------------------------------------------------------------

   Class Method Create()
   ' Do initialization

      ' Set defaults
      mwsKey = "Default key"

   End Method
'------------------------------------------------------------------------------


   Interface IMYInterface
      Inherit Dual


      ' *** Property Key
      Property Get Key() As WString
         Property = mwsKey
      End Property
      Property Set Key(ByVal wsValue As WString)
         mwsKey = wsValue
      End Property
'------------------------------------------------------------------------------

      Method ToVariant() As Variant

         ' Does work
         Method = mwsKey

        End Method
'------------------------------------------------------------------------------

    End Interface
End Class

[Knuth Konrad]

But for the life of me I don't know why I'd want to return a variant of a data item which is a WSTRING when I could just assign it (Post #3)

Because you're the guy that always asks for compilable code to be posted - and rightfully so. You also prefer the problem be compress to a small as possible sample, that demonstrates the behaviour. The actual problem I have is that an Win API expects a parameter passed as Variant and that passing a WSTRING variable works just fine, whereas passing a WSTRING property results in the mantioned compile time error. And that's odd, because that totally defeats the purpose of object properties.

And I was able to reproduce the behaviour within "PB boundaries" so I could exclude the API interface/PB definition of it to be the problem. Hence my posting here, because I still might have overlook something obvious.

[Chris Holbrook]

I thought that the whole point of properties is to allow code outside the class to get or set instance variables. So why attempt to use them inside a class?

[Stuart McLachlan]

I thought that the whole point of properties is to allow code outside the class to get or set instance variables. So why attempt to use them inside a class?

I agree. Inside the class, you can access the instance variables directly, so I don't see any value in increasing the code complexity by using the external Property Get.

[Knuth Konrad]

I thought that the whole point of properties is to allow code outside the class to get or set instance variables. So why attempt to use them inside a class?

The whole point of properties is to encapsulate the access to instance variables - regardless from where they're accessed from. Exposing variables through properties i.e. allows for various verifications/adjustments to the var's value, both before setting the instance var's value from the passed parameter, or before passing it back to the caller. One could also set other values inside the class, depending on the value passed, raise events and such. The whole point of a property is it's hybrid nature. For the calling code, it looks and behaves just like a variable. But from within the object itself, a property is both a variable and a function. That's what OOP is all about.

If the sole reason was to expose the instance variable to the outside, I just might make the variable public. I don't know any other object-orientated programming language, that doesn't allow you to access the instance variable's value through it's associated property from within the object itself.

[Chris Holbrook]

Knuth, your frustration is evident. Maybe the owners of PowerBASIC can help you?

Practically, if Properties don't do what you want, why not just forget them and use Methods.

[Knuth Konrad]

I know how to work around the current issue. If you read my initial posting again, I simply wanted to know if a) I'm doing something wrong there (the most likely case most of the time), b) this is how it's supposed to work in PB or c) that's an "issue" with the compiler and needs to be fixed/is added to th ToDo list for future updates.

That's all I asked. As of now, that's unanswered, but given the following turmoil over how to use objects, I think this time c) might be the answer.

[José Roca]

The answer is simple: it's an unsupported feature. Similar to returning an IDispatch pointer and trying to assign it to an object variable on another type. You have to use an intermediate step.