Error XS1558 'Functions' does not have a suitable static Start method

[ic2]

Despite Wolfgangs advice to start over with a new WPF project I still try to build in WPF in the existing program.

After a couple of changes, the current error keeps coming:
Error XS1558 'Functions' does not have a suitable static Start method
Functions is one of 2 programs which only contains functions. It SHOULD not have a start method! I tried to avoid this by adding some namespace, class and/or start code but the only result was parser errors.

Eventually, I copied the functions into the other program with functions which did not seem to give an error and removed the original functions.prg. Same error, this time again without a line number. After an external file content check on "Functions" I removed every reference to it (but these were only in *.vi* files, so for Vide and as I use VS it did not make a difference.

What does this message mean? Where does it come from and from where does it get 'Functions' while this is nowhere to be found anymore?

Did I tell you I hate Visual Studio? These kind of puzzling errors simply do not occur in the repo based Visual Objects code where you can basically put any method or class anywhere, move it and it just works. In VS, just a space in the wrong place keeps you busy for hours with cryptic error messages.

Dick

[Chris]

Hi Dick,

This looks like an unlucky situation, "Functions" is a special name used by the compiler for the class that holds the functions that you declare in your code (functions are included as methods of this class) and there's a naming conflict with your name for the app. Try renaming your app/project to "Funcs", instead of "Functions", does it work ok now?

Chris

[ic2]

Hello Chris,

I already deleted functions.prg and the error persisted. The other program with functions is called Functions_MyClient.prg and renaming that to Funcs_MyClient.prg does not solve the issue.

It did not give this error earlier. Only when we started with adding a WPF screen we eventually ended up with this error.

Dick

[Chris]

Hi Dick,

Maybe you just have not included a FUNCTION Start() then?

If that's not the case, can you please zip and send me the solution to have a look?

Chris

[wriedmann]

Hi Dick,

you need a typed Start() function.

Wolfgang

[ic2]

I have no function Start in my other X# solution for functions.prg because it is not the main program. So I don't expect the error here.

But to be sure I didn't miss something I started a new program, copied all files, included all DLL's etc. It worked. I entered the original WPF content and unfortunately I am back with my original error Partial declarations of '{0}' must not specify different base classes.

I clicked until the point I have only the basic XAML code again but still it doesn't work.

Chris, I will send my project. You have often seen the problem in a very short time before, hopefully you'll see it now as well.

Dick

[wriedmann]

Hi Dick,

then your application needs to be defined as library, not as Windows executable.

An application needs a start() function, a library does not.

Wolfgang

[ic2]

Hello Wolfgang,

then your application needs to be defined as library, not as Windows executable.
An application needs a start() function, a library does not.

No, that's not the problem. The application has the whole startup in the WPF generated code behind like the IntializeComponent(). Apart from that a few other prg's are included with functions or other methods. This method with functions does not need a startup method; that works exactly the same way in another WPF X# program of mine.

Currently Chris has the rebuilt WPF solution with the "Partial declarations of ... must not specify different base classes" error & the Functions included. If he knows what causes the problem there the other one hopefully stays away. And maybe even the original 'rebuilt' VO window program will work then.

Dick

[Chris]

Hi Dick,

Thanks for sending the code and sorry for the delay.

Turns out this is a small compiler bug, the same partial class is defined in the (auto generated) .g.prg file with a clause "INHERIT System.Windows.Window" while in your .prg you are using "INHERIT Window". Practically those two are the same, but seems the compiler could not figure this out, while it probably should.

Anyway, fortunately the fix is easy, change your inherit clause to the same as in the .g.prg file (INHERIT System.Windows.Window), or simply completely remove the INHERIT clause, the compiler will now see only the other one, will use it and there will be no conflicts.

Chris

[robert]

Chris,

I don't think this is a compiler bug.
The problem with the "INHERIT Window" is that there is also a class Window in the GUI library that is included. And since the compiler option "Enable Implicit Namespace Lookup" is enabled then the compiler will find the Vulcan.VO.Window class for this INHERIT clause.
This of course is not correct.
The only thing that the compiler could have done better is probably reporting that there is ambiguity here.

Robert

Turns out this is a small compiler bug, the same partial class is defined in the (auto generated) .g.prg file with a clause "INHERIT System.Windows.Window" while in your .prg you are using "INHERIT Window". Practically those two are the same, but seems the compiler could not figure this out, while it probably should.

Anyway, fortunately the fix is easy, change your inherit clause to the same as in the .g.prg file (INHERIT System.Windows.Window), or simply completely remove the INHERIT clause, the compiler will now see only the other one, will use it and there will be no conflicts.

Chris