...where X# is right (and VO sooo easy)

[ic2]

Just for info. We had a bit of trouble getting a 90% rotated font in a bBrowser. Turns out that this works in VO!

Code: Select all

LOCAL oFont AS font
			oFont := Font{, 8, "Arial"}
			oFont:Rotation := 900		

If you open oFont it will open CLASS Font INHERIT VObject. If you open Rotation you get _DLL access Rotation class Font:bBrw40.12

So defining a local oFont from the default VO Font class and then assigning a property which only exists in the (extended) bBrowser subclass simply works. I don't understand why but it's very easy

I think it's good it didn't work in X# (where it was solved by defining oFont as the bBrowser Font class.

Dick

[robert]

Dick,

The X# font class has a property Orientation. That maps to the same field that the bFont rotation maps to.
So if you change the code to use the Orientation property then it works.
We use that word, because the field inside the logfont structure from the Windows SDK also uses the word orientation and not the word rotation.

Robert

[ic2]

Hello Robert,

That's good to know although inheriting from the bBrowser font (and keeping it Rotation) works too.

I still don't understand why it works in VO this way.

Dick

[Chris]

Hi Dick,

Most likely the bBrowser library in VO defines this ACCESS which extends externally the Font class from the VOGUI classes directly, does not do it in the inherited class bFont.

In the .Net version of bBrowser this is done in the inherited class, so it's only available when you use that class, not only the parent class Font.

[ic2]

Hello Chris,

That looks like a good explanation. I was just wondering why it could work in VO. I think both ways are good but the X# way is more what you expect.

Dick

[wriedmann]

Hi Dick,
PMFJI: the explanation why it works in VO is clear: VO does most of its binding at runtime (when it comes to objects).
So, when you load start an application, all classes that are referenced (even these that are in referenced DLLs) are loaded in memory and the method table is built (at runtime).
Therefore you can add a method to a class from another DLL without creating a subclass (in your example it was the font class).
The .NET runtime instead builds the method table each class at compile time, and for each assembly separately. That excludes such "dirty" tricks that VO allows (and that most of us have used).
Wolfgang