xsharp.eu

This prg contains the direct methods called from the buttons and the toolstrip of the Winform window. Most code is in a separate program as a result of an earlier X# bug (now long solved) that code could get lost.

I removed everything except the namespace/class which restored the Designer window. Then I pasted all content again and got the Designer error back. So far so good. After some structured removing and restoring of data, the problem was a method which ended with
There should have been a // after the END Method; adding that restored the designer.

First I thought it was because there were 2 RETURNS in the same method (with only some commented code in between, hence the issue). Not sure if that could be a problem in another situation and if the compiler should catch that? But it could be a good idea if the compiler could catch an END METHOD followed by uncommented code, as Visual Studio's (2019) Winforms Designer has a problem with it. And apparantly, only in a later update (of VS or X#); the same code works perfectly in the mentioned older versions of VS/X#.

Anyhow, thanks for helping me find the issue and I hope it helps you too!

Dick

Hi Dick,

You're welcome, glad you have found the cause!

About END METHOD, followed by garbage, it's VO's fault . In VO it is allowed to put anything after an ENDIF, NEXT, END CASE etc and the compiler does not complain, so we added some preprocessor directives also in X# to ignore any text after such commands. Not sure I like this, but then again without it possibly a lot of existing (in VO) code would not compile. Those directives are only used by the compiler, the VS parser does not use them, hence the error in the designer.

About double RETURN statements, you should be getting a warning from the compiler: warning XS0162: Unreachable code detected. Maybe you have this specific warning disabled (in the project options)?

Guys, should work, the preprocessor takes care of it. There is a rule inside XSharpDefs.xh that strips the garbage.
I suspect that the compiler option /nostddefs has been enabled on this project?
Is that correct?

Robert

Robert,

The compiler/preprocessor accepts it, it's the form designer that chokes on it.

Somehow my reply got lost - in short:
1) Yes, there are still many warnings in my project, no doubt this warning would have been (correctly) in the list
2) I would suggest that the compiler not allowing a comment without // behind ENDIF etc is maybe better - it requires one time adding // in code but prevents the Winforms Designer to fail
3) I was wondering why the VS Designer fails on basically unrelated code. I can understand when this would happen in the .designer program but why would it fail in the "View code" program.
Dick

Dick,
3) We need to parse the other files with Form code to tell the Windows Designer about the events that exist for the form.
Usually the events are in form.prg where the event is registered inside the form.designer.prg.
If you have moved the events to another file, then we also need to include the methods from that file to make the designer happy.

Robert

Hello Robert,

You've indeed explained that earlier; hence we changed our design such that all the events 'generated' from the form are in the 'View Code' program (in which the rest of the code is called from another program). So in a sense what you say is that the code is actually related (as it is an event from a control on the form). It does however make me wonder how they designed the designer; contrary to WPF one would say that an event (including the 'offending' one) doesn't influence the design of the window itself whatever the code does, so it shouldn't influence the designer either.

But obviously that is not something you can help.

Anyway, I am happy that Chris helped me find the cause and I hope it helps others who will read this in the future.

Dick