xsharp.eu

Posted: **Wed Jan 24, 2024 11:38 am**

Kees,
The constructor of class DisplayInheritChild does NOT call SUPER().
As a result the compiler adds an automatic call to the SUPER() constructor before the MessageBox.Show()

If you add a call to SUPER() somewhere in that method then can control the order in which things are called.
By the way: in the XSharp Core dialect the SUPER() call must be the first statement in the constructor().
In the other dialects, you can have the SUPER() call anywhere in the method.

I changed the constructor of DisplayInheritChild to:

Code: Select all

CONSTRUCTOR() CLASS DisplayInheritChild
		MessageBox.Show("DisplayInheritChild - Constructor()", "Information", MessageBoxButtons.OK, MessageBoxIcon.Information)
                SUPER()
		//SELF:PostInit() no need to call this. The SUPER() constructor already does that.
	RETURN

Then I see the following messages

DisplayInheritChild - Constructor()
DisplayInheritParent - Constructor()
DisplayInheritChild - PostInit()

Robert

Posted: **Wed Jan 24, 2024 4:03 pm**

Kees,

If you want to completely avoid calling the parent constructor (in other words prevent the compiler from implicitly adding code to call it), you can use this trick:

Code: Select all

	CONSTRUCTOR() CLASS DisplayInheritChild
		IF FALSE
			SUPER()
		END IF
		SELF:PostInit()

This way the compiler sees that you have a call to the parent constructor, so it does not add one also. But this call is never executed, so the parent constructor never executes either.

But please don't tell Robert that I suggested this

Posted: **Wed Jan 24, 2024 4:17 pm**

Robert,

The behaviour is still different from VO. If I do not make the call to SUPER then the compiler adds it automatically. This does not happen in VO.

In the following VO code:

Code: Select all

CLASS DisplayInheritParent
METHOD Init() CLASS DisplayInheritParent
	InfoBox{, , "DisplayInheritParent - Init()"}:Show()
RETURN SELF

CLASS DisplayInheritChild INHERIT DisplayInheritParent
METHOD Init() CLASS DisplayInheritChild
	InfoBox{, , "DisplayInheritChild - Init()"}:Show()
RETURN SELF

FUNCTION DisplayInheritanceTest()

LOCAL oObjectChild AS DisplayInheritChild

oObjectChild := DisplayInheritChild{}

RETURN NIL

only the Init from the child class is executed. In X#, since the SUPER is automatically added, both Inits / Constructors are executed. The VO code may depend on the Init from the parent class not being executed. What should I do to get the same behaviour after conversion to X#?

Kees.

Posted: **Wed Jan 24, 2024 4:21 pm**

Chris wrote: ↑Wed Jan 24, 2024 4:03 pm If you want to completely avoid calling the parent constructor (in other words prevent the compiler from implicitly adding code to call it), you can use this trick:

Hi Chris,

I was working on my reply while you added your reply so I did not see it in time. Thank you very much! That workaround should do it

Kees.

Posted: **Wed Jan 24, 2024 5:04 pm**

Chris,

Chris wrote: ↑Wed Jan 24, 2024 4:03 pm But please don't tell Robert that I suggested this

You naughty boy. You should not tell people to do this!

Robert

Posted: **Thu Feb 29, 2024 11:50 am**

Hi all,

Finally, after hours of searching and experimenting I found the solution to a VO menu-problem in X#. What I did was copy the files that define a menu (the .prg and the .rc and .xsmnu files) that were exported with VOXPorter, to the X# solution folder and add them as existing items. It worked very well, until I added a menu in the X# VO menu editor. This resulted in a very strange mix of the old and the new menu. The rightmost menu had disappeared and all menu options had moved one menu to the left, down to the menu that was added. But … everything looked correct in the menu editor. And when I copied the files to a new test solution, it displayed correctly in that solution.

The cause of the problem turned out to be that the original versions of the .rc files of the menu were in the Properties folder of the solution, while the modified versions (with the added menu) were in the solution folder. So for editing the menu the .rc files in the solution folder were used and for run-time the .rc files in the Properties folder were (at least partially) used. When I copied the .rc files from the solution folder to the Properties folder everything was ok again.
Note: In my test solution the .rc files are not in the Properties folder but only in the solution folder.

Questions:

Is there a setting that determines the location of the .rc files?

Should the .rc files be added separately to the solution with “add resource” while the .prg and .xsmnu files can be copied to the solution folder?

If the .rc files are present in both locations (old and new versions), why are both combined to create some strange version of the menu?

Kees.

Posted: **Thu Feb 29, 2024 12:59 pm**

Hi Kees,

The .rc and .xsmnu files are only supposed to be subnodes of the main prg node, they should not be in the properties folder. Having two versions probably resulted to the windows resource compiler combining both into one.

The easiest way to copy a menu to another solution is to add a a new menu item in the new solution, giving it the name of the old menu, this will create the correct file structure. Then you can copy the .prg and .xsmnu files from the old solution to the new one, overwriting the empty menu files you just created. Then open the menu in the menu editor, make sure it contains the menu structure that you intended and do a save, this will also update the .rc file contents, you do not need to copy the .rc file manually at all.

Posted: **Fri Mar 01, 2024 8:26 am**

Chris wrote: ↑Thu Feb 29, 2024 12:59 pm The easiest way to copy a menu to another solution is to add a a new menu item in the new solution, giving it the name of the old menu, this will create the correct file structure. Then you can copy the .prg and .xsmnu files from the old solution to the new one, overwriting the empty menu files you just created. Then open the menu in the menu editor, make sure it contains the menu structure that you intended and do a save, this will also update the .rc file contents, you do not need to copy the .rc file manually at all.

Hi Chris,

Thank you for your reply, it sounds like good advice. So I deleted the menu in the VS Solution Explorer first and I also deleted the copy of the menu files in the Properties folder, where they should not be as you said. Unfortunately I now get a compile error:

MSB3375: Input file: F:\BP\RightsManager\Properties\Standard Menus.StatusBarMenu.rc not found
C:\Program Files (x86)\XSharp\MsBuild\XSharp.CurrentVersion.targets 146

The strange thing is that in the file C:\Program Files (x86)\XSharp\MsBuild\XSharp.CurrentVersion.targets (which appears to be an XML document) there is no reference at all to the properties folder.

Line number 146 in this file is the first line of this piece of XML ("<NativeResourceCompiler"):

Code: Select all

    <NativeResourceCompiler
       Sources="@(NativeResource)"
       IncludePaths="$(IncludePaths)"
       OutputPath="$(IntermediateOutputPath)"
       EmitDebugInformation="$(EmitDebugInformation)"
       DefineConstants="$(DefineConstants)"
       SuppressRCWarnings="$(SuppressRCWarnings)"
       Condition="'@(NativeResource)' != ''">
    </NativeResourceCompiler>

What should I do to get rid of this error?

Kees.

Posted: **Fri Mar 01, 2024 9:21 am**

Hi Kees,

It's very difficult to say what the current state of the solution is, after all those manual deletes and adds. Can you please send me your solution so I can have a look?

Posted: **Fri Mar 01, 2024 9:32 am**

Chris wrote: ↑Fri Mar 01, 2024 9:21 am It's very difficult to say what the current state of the solution is, after all those manual deletes and adds. Can you please send me your solution so I can have a look?

Hi Chris,

It seems I have already found it. I discovered that in the Solution Explorer, the menu files in the Properties folder (although I deleted them) were still listed in the "Properties" section so I removed them there as well. I also did a "Clean Solution" from the Build menu. Now everything works again.

Thanks for your help!

Kees.

xsharp.eu

Miscellaneous questions about converting VO code to X#

Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#

Re: Miscellaneous questions about converting VO code to X#