I don't think this sample and class was intended to be used like that. If you start with a Windows.Forms app, then the winforms form is supposed to be used as the "Shell" and not have again a VO style ShellWindow. Instead, you can show VO style DataWindows etc, hosted inside a winform.
If you want to keep using a VO Shell window, then I think you need to use the other sample, still have a VO style app and add winforms to it.
Hi Chris,
Thank you for your reply. I have changed the sample so that instead of a VO.ShellWindow a VO.DataWindow is used (see attachment). Now the runtime error on closing the window has disappeared, but the menu is still not displayed. Also, closing the VO window with EndWindow() does not close the host window. I do understand that, because the VO window knows nothing about the host. But how can closing the host window together with the VO window be done from within the VO window? I know there is a method CloseHostForm() in the WinFormVOWindow class but since the VO window knows nothing about the host there is no way to call that.
Anyway, if you are right, then the functionality of these hybrid classes is extremely limited. You can only use a datawindow without a menu, and who knows what other limitations there are. This combined with the lack of documentation and working X# examples (except for some very old Vulcan material) makes me think it may be better to remove these classes from X#.
I don't think we ever encouraged people to use those classes, we know they have issues, but in case someone had successfully used them in vulcan, then why not having them as an option in X#, too?
Will have a look though, maybe there are ways to workaround the issues you reported, just had never used those myself, so can't give you a direct answer.
Hi Kees,
the VOGUI window needs to know it has a Windows Forms owner window that is also to close, otherwise it will not work.
Therefore every VOGUI window will have to be of a special subclass of the DataWindow class that has exactly this functionality.
I agree with Chris that this functionality is not perfect - it is a hybrid approach that for sure has some shortcomings, but has really great advantages if your situation requires it.
But as always in these cases, you have to try out the code and eventually adapt it to your needs.
Wolfgang
Wolfgang Riedmann
Meran, South Tyrol, Italy
wolfgang@riedmann.it
https://www.riedmann.it - https://docs.xsharp.it
I would also say that the hybrid solutions are a good workaround to put together two worlds for a limited time. But there are some heavy disadvantages and risks with this solution.
Some years ago programmers from a big company presented such a hibrid solution, where they used Winforms as the Shell window and container windows where they implemented their existing VO-GUI-Windows. They got to work every old window. But they said immediately that it was only to have time to redesign all VO-GUI-Windows with Winforms-Possibilities.
May be the GUI-Classes with Winforms internally can avoid some of the problems using hybrid solutions?
I don't think we ever encouraged people to use those classes, we know they have issues, but in case someone had successfully used them in vulcan, then why not having them as an option in X#, too?
Will have a look though, maybe there are ways to workaround the issues you reported, just had never used those myself, so can't give you a direct answer.
Hi Chris,
Thank you very much in advance for looking into it. The runtime error when closing the window seems to be common to all the examples I have seen. Maybe it worked in Vulcan but that error appears always in X#. Also it would be necessary in my case that the menu of a shellwindow can be shown. Anything you can do is very much appreciated!
I don't think we ever encouraged people to use those classes, we know they have issues, but in case someone had successfully used them in vulcan, then why not having them as an option in X#, too?
Will have a look though, maybe there are ways to workaround the issues you reported, just had never used those myself, so can't give you a direct answer.
Hi Chris,
Thank you very much in advance for looking into it. The runtime error when closing the window seems to be common to all the examples I have seen. Maybe it worked in Vulcan but that error appears always in X#. Also it would be necessary in my case that the menu of a shellwindow can be shown. Anything you can do is very much appreciated!
Had been away for the weekend, will look into it in the next days. But especially about the Shell window, since you're starting with a Windows.Forms app, what's the point of having a VO style shell window? I don't think those classes were designed with supporting this in mind, so I suspect there will be plenty problems trying to fully support it.
Chris wrote: Mon Sep 29, 2025 2:43 pm
Had been away for the weekend, will look into it in the next days. But especially about the Shell window, since you're starting with a Windows.Forms app, what's the point of having a VO style shell window? I don't think those classes were designed with supporting this in mind, so I suspect there will be plenty problems trying to fully support it.
Hi Chris,
The application was originally made in Visual Objects including the shellwindow, a splitwindow with bBrowser controls and a very extensive menu. Re-creating the menu system for a Windows.Forms form would be a lot of work and complicated because of the code the menu options execute. The menu is changed in the code as well. So I would like to keep that as it is for a while. Re-creating the entire window would be even more work. There is a lot of code attached and the bBrowsers can't be translated easily to Windows.Forms. Eventually it will have to be done but hopefully then there will be a bBrowser version that works in Windows.Forms.
In my eyes it is better to completely stay in WinAPI VO-GUI or completely move to Winforms.
I agree with Wolfgang that probably there won't be any Winforms bBrowser in the future. Our company has rewritten our code based on the BBrowser on top of the Winforms Devexpress controls adapted to what we need. It was a work of many months. If we gave you the source code, then you would have to spend many other months to re-adapt it to the original bbrowser functions.
If you want to use Winforms partially, then it can be a possibility to develop a new program using only Winforms and to connect the old VO-GUI-program and the new program presenting to the user a "hybrid" solution.
i believe the real problem is that few are willing to invest money to have bBrowser for Winform.
I would be willing to spend on a broader project that could also include a report generator compatible with Report Pro.
How much money? A few thousand euros without issue.
If there are other people like me willing to invest, step forward!
I believe there will be very few of us.
