xsharp.eu

Robert,

Oops, I didn't notice the references to the SDK classes! Good point

Chris

Hello Chris, Robert,

That solved this error, thanks. I think a change in the compiler message would help indeed, but even adapting the compiler error in the help would work for me.

However, unfortunately, I still can not get the program working. I've spent considerable time and started over a dozen times (also every time trying to get rid of the unwanted WpfApplication1 tags. In a a couple of instances I ended up with a Xaml designed in which I could not click or drag controls into. I guess I already wrote you that I hate Visual Studio ? )

Anyhow: after a while I could compile the project I mailed Friday but nothing happened when I started it. In the debug mode I found that it didn't even get beyond app:Run() where it gives an XamlParseException error. See picture.

I thought it could be that I included references to Vulcan 4 DLL's while I also have a ADS DLL included which is based on Vulcan 3. I removed the references and added a reference to all Vulcan DLL's in C:Program Files (x86)Vulcan.NET 3.0RedistAssembliesv4.0. This had another nice effect: Visual Studio quickly came with a box "The operation you requested is taking longer..." (See picture). Te first time I had to use Task manager to kill VS. As it's VS I decided to give it some more time the 2nd try but after an hour it still showed this message . However: this time some clicking gave the error message as in the attached picture.

I removed the Vulcan references starting from the backup project. I added a reference to only the few Vulcan 3.0 DLL's the program needs to compile, this time it compiled, but it still doesn't get beyond the app:Run(). As I built this a a WPF X# program from scratch I am out of ideas how I could get this working otherwise, especially since I have 1 working X# WPF application and I don't see any real differences.

Except for some globals I added as a temporary solution + 2 included prg's with functions, I have not even added the converted VO code yet.

Can I ask you Chris to have another quick look as to why this project fails to start? I have uploaded the project in the same link as I mailed you Friday. Hopefully you have an idea quickly.

Dick

(and for going back to the original question):
If I continue with a working and starting WPF application, the Vulcan DLL's included but no converted VO code yet, the error immediately returns when I change the dialect from Core to Vulcan.

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

Note that I did NOT yet include the prg called Function.prg with function it it.
This error is the direct result of changing Core to Vulcan. I've set the language settings equal to those in my working # program (Allow Unsafe code, Enable implicit Namespace lookup, Implicit signed/unsigned conversions and Treat missing types as usual) to true but this error won't disappear.

Does this give more info?

Note that this question is from a different version of the project than the question below. But I'd say in the end both should lead to a working X# WPF program....

Dick

Hi Dick,

Found the problem, it was due to the Project PropertiesLanguage page"Implicit CLIPPER calling convention" compiler option. Set that to False and it should work fine.

I know, you will say that you did not have such strange problems in VO, but that's because VO's compiler does not have many of the features that .Net compiles have, like method overloading which is the culprit in this case. Also it does not help that WPF is designed to create and use "ghost" .prg files, which are not visible in the solution explorer, so it is hard to debug such issues.

Anyway, the problem is caused because a method (InitializeComponent()) that the designer created in such a file (KleijnOCRScan.g.prg) has no parameters, and the above compiler option gives such methods CLIPPER calling convention, for compatibility with VO code. The system expects a STRICT method though, thus the runtime error.

Chris

Hi Dick,

About the problem with Start(), it could be due to the same reason. Try setting the same option to False, does it fix the compiler error? If it doesn't, do you have defined a FUNCTION Start() yourself in that project? If yes, how exactly have you defined it?

Chris

Hello Chris,

YES, that fixes it! I thought I already had created a version with minimal compatibility language settings to true but apparently that was only with the 2nd problem. Although this is not important for the project, which Jelle can continue Monday thanks to you even replying in the weekend (!!) I will certainly double check the settings there too (I've got about a dozen copies of the project in various stages now) and should this be another issue I may send you a copy once again.

In return I'll promise to create a chapter in "Wolfgangs Wiki" for anyone who needs to do the same.

I know, you will say that you did not have such strange problems in VO, but that's because VO's compiler does not have many of the features that .Net compiles have, like method overloading which is the culprit in this case. Also it does not help that WPF is designed to create and use "ghost" .prg files, which are not visible in the solution explorer, so it is hard to debug such issues.

Actually yes and no. I fully realize that creating a language which needs to be compatible with >20 year old VO code is a hell of a job and these kind of problems occur now and then.
I do however also see again and again that the design of VS and the compiler, lets put it friendly, leaves much to be desired. The ghost .prg/.cs files are terrible and makes understanding how the program works almost impossible. And the ambagious references, where it all started with, are present as well in C# where this backward compatibility wasn't an issue. Example: you enter

string cDestFile = Path.Combine(cDestDir, cNewName);

and the compiler begins to complain that Path is ambagious because some idiot forgot to check that Path already existed in System.IO when he chose the same name for System.Windows.Shapes so you must use string cDestFile = System.IO.Path.Combine(cDestDir, cNewName);

VS and C# are all lousy & lazy designed.

Anyhow thanks again; I'll be back with info about the Start method error soon.

Dick

Hi Dick,

I agree about the ghost code files in WPF, I also don't understand what they were thinking what they designed this (and a few other things) this way.

About the "Path" thing, "problem" is that there are literally millions of classes that you can use in any .Net language, either system ones or from 3rd party libraries, so it is inevitable that there will be naming conflicts. At least in .Net we have the concept of namespaces, so you can fully qualify the class name and problem solved. I am wondering if there is any solution at all in VO, when you try to use 2 libraries that have class with the same name...

In any case, glad you have it working now!

Chris

ps. it's not just a weekend, for us down here it's also the orthodox Easter weekend!

Hi Dick, hi Chris,

as you both know, I'm far from liking Visual Studio <g>.

WPF is very wonderful and extremely powerful, and that makes it hard to master. With Visual Studio Microsoft has tried to let if master by point-and-click programmers, and it took years and several versions until the Visual Studio XAML editor finally worked.
Of course, to make work such a complex beast as WPF in a apparently easy-to-use tool requires many compromises and includes also hidden details (like the .g.prg files needed for the X#/C# compiler to "know" what whas defined in the XAML file).

I can assure you that I don't like at all the way Microsoft has designed the XAML integration in Visual Studio, but I think that this was not an easy job, and I cannot immagine another one without these hidden files.

If you look around you will find many material about WPF, and many incredible complex XAML code samples, and therefore my conclusion is that basically Microsoft has selected the right way for its development tool.

Anyway, there are much easier ways to build WPF code if you look behind the scenes and you are willing to write some source code (that can then be used also in XAML).

Hopefully, my two sessions at the Cologne conference will give some new insights how you can simplify and power WPF applications (I have finished the last sample for the second session yesterday....).

Wolfgang

P.S: I'm planning to write a standalone WPF window editor - an editor that writes X# code (or C# code) and stores the windows definitions in text files. This editor will not be a two-way editor like the one in Visual Studio, but a one-way editor like the one in Visual Objects, and it will let you use your own control and window classes as a easily as the VO Window Editor and the XIDE window editor. And it will be open source, in the hope to beocme better that way

Hi Wolfgang,

Really looking forward to have a look at your editor, when you have some first versions of it!

But at least regarding the ghost files, I'm pretty sure those could had easily been made "public", just like the files generated by the WinForms editor, but apparently the WPD team decided otherwise...

Chris

Hi Chris,

you can be sure to see the first working prototypes as I will need your help to integrate into XIDE....
But unfortunately I have to do a few other projects before....

Wolfgang