fbpx
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Xported project: Error XS1061 'type' does not contain a definition for ..

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6090

  ic2's Avatar Topic Author ic2 Offline Posts: 485
In an XPorter converted VO project we get a few 100 errors like this:


Error XS1061 '__Usual' does not contain a definition for 'Close' and no extension method 'Close' accepting a first argument of type '__Usual' could be found (are you missing a using directive or an assembly reference?)

Code is simple things like:
SELF:Server:Close()
All Vulcan includes are present and Treat missing types as usual is True.

What helps is to set Allow Late binding to true; then the errors disappear. But apart from that it's not completely clear to me what I am doing, it should not be necessary. We have other working projects without this option. I am obviously missing something but I can't see what.

PS: the X# CHM help shows both for the /lb compiler option and the XS1061 error Example code. For the /lb it only shows empty boxes; for the XS1061 it only shows // XS1061.prg in the box. So the actual example code is missing.

Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6091

  wriedmann's Avatar wriedmann Offline Posts: 1567
Hi Dick,

I'm answering because I had a similar problem and have discussed it with Chris.

For VO projects, you need late binding.

Otherwise you have to type all these objects or cast them to something, or use the Send() function (as I did because in my code a typing was not possible because in my application the types were available only at runtime, and not at compile time).

Wolfgang

P.S. removing this option would need a rewrite of your code, and a strong adoption of interfaces
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6092

  ic2's Avatar Topic Author ic2 Offline Posts: 485
Hello Wolfgang,

Ok - but if I change it to a Vulcan project I get the same number of errors. Vulcan libraries are included so I'd expect something like self:Server to be available at compile time?

Other errors refer to GUI elements, like self:browser or something like SELF:ToolBar:PressItem(IDM_StandardShellMenu_View_Table_ID)

Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6093

  wriedmann's Avatar wriedmann Offline Posts: 1567
Hi Dick,

self:Server in the class DataWindow is a non typed access variable, so the compiler cannot know what type it returns.
Therefore it is of type "usual", and the datatype "usual" has no method Close().
The compiler is also right.
If you use the "late binding" option in the compiler, under the hood the compiler translates
oWindow:Server:Close()
to code similar to
Send( oWindow:Server, "Close" )
And therefore the method call will be resolved at runtime and not at compile time - also late binding.

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6094

  ic2's Avatar Topic Author ic2 Offline Posts: 485
Thanks Wolfgang,

It looks like that's indeed the case. I have one other X# solution without Late Binding but this opens databases directly, like

SELF:oDBSomedb := IC2DBServer{cDataPath + "somedb.dbf", TRUE, FALSE}

and

CLASS IC2DbServer INHERIT DbServer
CONSTRUCTOR (oDbf_FS, lShare, lReadOnly) // Class IC2DBServer
SUPER(oDbf_FS, lShare, lReadOnly)


Then it works without this error. So it probably works without Late binding if we subclass self:server as above.We have to check that.

Point is otherwise that I wonder how much we actually gain from converting VO projects to X# with late binding on. From the documentation: late-bound calls can affect the performance.

Plus compiler errors which would normally point to a method which isn't available at runtime either are suppressed so it will actually make your X# program much more vulnerable to run time errors than a VO program. E.g. this compiles fine:

SELF:Server:Dosomethingwhichdoesnotexist()


Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6095

  Chris's Avatar Chris Offline Posts: 1164
Hi DIck,

It's exactly what Wolfgang said, in SELF:Server:Close(), "Server" is known ar compile time, but its type is USUAL and "Close()" is not known at compile time, this will be resolved at runtime, thus late binding is necessary.

It would had been completely different if "Server" was strongly typed in the SDK, so it was declared for example as

ACCESS Server AS DataServer

in this case, everything would be known at compile time and no lated binding would be involved at all.

CHris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6096

  Chris's Avatar Chris Offline Posts: 1164
Hi Dick,

ic2 wrote: Plus compiler errors which would normally point to a method which isn't available at runtime either are suppressed so it will actually make your X# program much more vulnerable to run time errors than a VO program. E.g. this compiles fine:

SELF:Server:Dosomethingwhichdoesnotexist()


Exactly, absolutely the same as in VO...For these reason it is useful equivalently in both VO and X# to use early binding than late binding.

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6097

  wriedmann's Avatar wriedmann Offline Posts: 1567
Hi Dick,

no, this has not to do with your subclassed server, but probably self:oSomeDB is known at compile time (either as instance variable or as strong typed access). Therefore the compiler knows the correct method to call at compile time.

Point is otherwise that I wonder how much we actually gain from converting VO projects to X# with late binding on. From the documentation: late-bound calls can affect the performance.

Plus compiler errors which would normally point to a method which isn't available at runtime either are suppressed so it will actually make your X# program much more vulnerable to run time errors than a VO program. E.g. this compiles fine:

SELF:Server:Dosomethingwhichdoesnotexist()


In VO, you are using late binding. Therefore I don't think X# will be slower or less stable if you are using late binding with it.

I have to confess that I use late binding a lot, and also the Send(), IVarGet() and IVarPut() functions.

To make stable and performant code for sure late binding is not the best option, but it makes me much more productive.
Otherwise you will have to work with interfaces, and rethink the application structure.

This may be the case for new applications, but for sure not for migrated ones.

Fortunately X# gives us the choice: late binding as in VO or not.

Wolfgang

P.S. I would like a pragma in the code to switch late binding on or of when needed....
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6098

  ic2's Avatar Topic Author ic2 Offline Posts: 485
Hello Chris, Wolfgang,

Exactly, absolutely the same as in VO...For these reason it is useful equivalently in both VO and X# to use early binding than late binding.


Indeed! I never realized that but VO accepts this too. And we also use send(#) regularly in VO; e.g. we have a couple of main programs for different client(types) where sometimes a client (type) specific methods replaces the regular method and this one resides in the main program which we can call from the included lib thanks to ismethod and send(#).

So good to know that I didn't miss something obvious and late binding is a normal practice. I assume this can be abandoned as soon as we have the Core X#.

Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6101

  FFF's Avatar FFF Away Posts: 574

ic2 wrote: I assume this can be abandoned as soon as we have the Core X#.

If "this" means, late binding, i wouldn't know, why. LB lets you use calls to types you don't know at compile time, that won't change because the runtime changes.

Karl

Please Log in or Create an account to join the conversation.

Last edit: by FFF. Reason: typo

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6102

  wriedmann's Avatar wriedmann Offline Posts: 1567
Hi Dick,

So good to know that I didn't miss something obvious and late binding is a normal practice. I assume this can be abandoned as soon as we have the Core X#.


It depends on your programming style, it has nothing to do with the X# runtime.

First of all, all access/assign variables should be typed. This will solve a lot of late binding (and I'm doing this already in VO whenever possible to be prepared for the X# move).

But there are many cases where late binding permits more elegant code - to make it without you would need to use interfaces.

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6111

  ic2's Avatar Topic Author ic2 Offline Posts: 485
Hello Wolfgang, Karl,

I still don't understand why the code above (with my subclass to dbserver) works without late binding or compiler errors. It has nothing else than the few not-strong-typed code I wrote. Also I don't understand why it's impossible that, on rewriting the code to a Core X# version, the init can not be made strong typed. But after all I am not a compiler builder ;)

Most intriguing for now is: what do I need to do if I want code like SELF:Server:Close() work without Late Binding? I mean: how can I solve that with access/assign variables? That's the majority of the 375 errors. Or can't I prevent these?

Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6112

  Chris's Avatar Chris Offline Posts: 1164
Hi Dick,

By definition, late binding in VO (so also in x#, if you ignore the Dynamic type for now) is code that uses USUALs; in other words not strongly typed vars, exports, return types etc. Whenever you use a USUAL to do any calculation or when you call a method on a USUAL, the compiler does not know what the USUAL will contain when the code will execute, so it generates generalized code for that, with no compile time checking. This is what's late binding, in very short and without using really official terminology :).

So no matter the compiler, when you use USUALs, no compiler knows what the usual will hold at runtime, so it always creates late bound code. In order to get rid of late binding, you need to get rid of the USUALs, mainly when you call methods/properties etc on USUAL vars. Of course this is not always easy, because some of those USUALs are declared in the SDK, so you'd need to modify the SDK code for that.

Alternatively, you can use an intermediate option, to use intermediate strongly typed vars, instead of operating on the untyped vars of the SDK or of your own code. For example, the code
SELF:Server:GoTop()

is late bound, because "Server" is a USUAL ACCESS of the Window class. But you could rewrite it like that:
LOCAL oServer AS DbServer
oServer := SELF:Server
oServer:GoTop()

which is a lot more "safe" and efficient that the previous code. It is still not perfectly safe, because it is not guaranteed that at runtime "SELF:Server" will indeed contain a var of type DBServer, so the assignment could potentially fail at runtime if "SELF:Server" happens to contain an instance of a class not inheriting from DBServer. But from experience we do know that "Server" will indeed hold a DBServer object, so it should work fine.

Then, the 2nd line is pure early bound code, which is efficient and type safe now, you cannot call a method that does not exist this way anymore. Furthermore, with this version of the code you will get help from intellisense with member completion, something you were obviously not getting with the early bound version. An alternative syntax for the above would be to use a cast in a single line:
((DbServer)SELF:Server):GoTop()

or
(SELF:Server ASTYPE DbServer):GoTop()

but the 3-line version is probably more readable.

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6114

  robert's Avatar robert Offline Posts: 994
Chris,

Internally the variable is a DataServer:

PROTECT oAttachedServer AS DataServer

So this should always work (except when SELF:Server is a NULL_OBJECT)

LOCAL oServer AS DataServer
oServer := SELF:Server
oServer:GoTop()

Of course this does not allow you to call methods that are DbServer specific, like SetOrder().

Robert
XSharp Development Team
The Netherlands
This email address is being protected from spambots. You need JavaScript enabled to view it.

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6116

  Chris's Avatar Chris Offline Posts: 1164
Robert,

Agreed, but that's a library implementation detail that we must somehow know about, that's why I said "we know from experience". My point was that when we use an intermediate var for a USUAL, or use a cast on it, we do improve things a lot, but still in general this "unsafeness" of converting the USUAL (so unknown type at compile time) to a strong typed var still exists. Complete solution and only way to enforce full compile time checking is to strongly type the ACCESS.

Chris
XSharp Development Team
chris(at)xsharp.eu

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 2 weeks ago #6118

  ic2's Avatar Topic Author ic2 Offline Posts: 485
Hello Robert, Chris,

LOCAL oServer AS DbServer
oServer := SELF:Server
oServer:GoTop()


Thanks for all the explanations. The above is what I basically do in the non late bound X# program. Sounds to me like a good solution to prevent late bound code.

Dick

Please Log in or Create an account to join the conversation.

Xported project: Error XS1061 'type' does not contain a definition for .. 9 months 1 week ago #6123

  wriedmann's Avatar wriedmann Offline Posts: 1567
Hi Dick,

exactly that is what I'm doing every time I touch VO code. And I don't use the generic server class, but the one that is used in this window, like this:
local oOrder as Order

oOrder := self:Server
....(method calls)....

But there are other places where compile time binding has a big performance advantage: in event handlers.
There I'm writing code like this:
method Dispatch( oEv ) class EnhancedSLE
local oEvent as @@Event 
oEvent := oEv
.....

Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
This email address is being protected from spambots. You need JavaScript enabled to view it.
www.riedmann.it - docs.xsharp.it

Please Log in or Create an account to join the conversation.

  • Page:
  • 1