Show X# VO-style window from WinForms project

Serggio · Post by **Serggio** » Sun Oct 25, 2020 6:08 pm

Disposition. I have 2 projects: an X# and C# ones. The X# project has a VO-style window, inherited from DialogWindow class with some basic controls placed on it. I want to create and show this window from the C# project, which uses WinForms.
The window appears but is blank - no controls are painted, they're not working, etc.
It seems to me that it's something about message queue which is not processed by the X# window when being called from the C# application.
How would you suggest to solve it?

Serggio · Post by **Serggio** » Sun Oct 25, 2020 6:53 pm

It seems that I should somehow use WinFormVOWindowHost, WinFormVOWindow and VOWinFormApp.
Haven't found yet how to do it properly.

wriedmann · Post by **wriedmann** » Mon Oct 26, 2020 6:18 am

Hi Serggio,
there was a sampe around.
Please find it attached (with some changes by myself).

HostingVO.zip: (14.99 KiB) Downloaded 98 times

Wolfgang

Serggio · Post by **Serggio** » Mon Oct 26, 2020 7:01 am

Thank you, Wolfgang!

I will look into it. As far as I see, I have to have a hosting WinForms window as a container for my VO-Window. It's something I have to settle my mind with.

wriedmann · Post by **wriedmann** » Mon Oct 26, 2020 7:08 am

Hi Serggio,
you have to do that because that container routes the messages from the Windows Forms window to your VO window.
The same applies for the inverse: hosting a Windows Forms window inside a VO window. In this case your container has to route the VO GUI window messages to the Windows Forms window.
It is really a great thing that this works. It will permit for example to host a Edge control in a migrated VO application - so you can have a full blown Chrome window in your application (the new Edge is based on Google Chrome).
Wolfgang

Serggio · Post by **Serggio** » Fri Oct 30, 2020 9:37 pm

After spending quite a long time I've found the reason why VO-windows refused to work properly when being shown from a C# WinForms application. The reason is in _INIT1 and _INIT3 procedures of VOGUIClasses.dll which have to be called. And if your main application is written in C#, which doesn't have a habit to run those init-procedures, then the message queue isn't working as it should. So you have to call them by yourself. And that may be done both in caller or in X# DLL in such a manner:

Code: Select all

	IF GetAppObject() == NULL_OBJECT
		VOGUIClasses.Functions.__WCInitCriticalSections()
		VOGUIClasses.Functions.__InitFunctionPointer()
		VOGUIClasses.Functions.__WCRegisterCustomControl()
		VOGUIClasses.Functions.__InitClassPointer()
		VOGUIClasses.Functions.__WCRegisterMMContWindow()
		VOGUIClasses.Functions.__InitTheme()
		
		App{}
	ENDIF

	// Show window...

This is quite a universal way to handle situation: if your DLL is loaded from X# application (in VO-dialect) then GetAppObject() would return a valid App object and there is no need to do more. But if your DLL is loaded from C# then no App would be instantiated and thus you imply that VOGUIClasses.dll is most likely not initialized either, so you have to do it yourself. The benefit of it all is that no proxy-windows like WinFormVOWindow are needed.
And I would be even more happy if there were a simplier way to call those functions, because I had to unfold $Init1 and $Init3 methods for they are not directly callable.

robert · Post by **robert** » Sat Oct 31, 2020 8:08 am

Serrgio,
We have created these $Init1 and $Init3 methods to be compatible with Vulcan.
They are used for calling init procedures and also to make sure that all types in assemblies that are referenced are initialized so you can create for example a server object with CreateInstance(#DbServer) without every directly referencing the DbServer class in code.
The names with embedded dollar characters are chosen to make sure that there is no name conflict with a method or function created in code.

Robert

Main menu