xsharp.eu

Hi Jeff,

I'm trying to break the VO paradigm really. I'd like to use the "new and improved VO" - X# methods instead. I'd like to ask a user do they really want to "close this window" or "close the app" etc using X# coding.

Please distinguish between the X# language and the Class libraries.
You have different layers:

• the X# language itself
• the .NET Framework classes
• the #X runtime
• the VO compatibilty classes

and then you have several GUI choices:

• Console and GUI-less applications like Windows services
• the VO compatible GUI classes
• WinForms applications
• WPFapplications
• other GUI class libraries like Xamarin etc.

Your GUI choice dictates what functions/methods you have to use in the GUI layer, but even if you use the VO compatible GUI classes, you can use all the new X# language extensions and the .NET Framework classes like collections, ADO.NET and other interesting things in the relative methods.
But you cannot mix GUI choices (or only in a limited mode).
Wolfgang

Hi Jeff,

BiggyRat wrote: Another thing that I can't really get my head around - PARTIAL Classes - what are they? Surely you have a Class, or you don't?

Further to what Robert said:

The easiest way to see how a partial class work. In XIDE (I assume that is what you using) right click in the projects folder on a .prg which have a "Designer" form. You will see a Add Designer option. I always do this.

You will then end with two .prg's

• MyForm.prg
• MyForm.<designer>.prg

All your "Designer drag and drops" onto your form will go into the PARTIAL CLASS MyForm in the <designer>.prg.

Your hard coded stuff, e.g. what clickevent method needs to be called, will go into MyForm.prg PARTIAL CLASS MyForm. It is just a nice way of splitting designer code from your own code. If designer mess up things, it only mess up the designer, not your blood sweat and tears.... Ask me, I experienced it many times in VO repo crashes. Luckily with XIDE/VS so far never happened.

HTH,

Hi Jeff,
let me add something to what Robert and Johan wrote:
in VO, you can distribute your methods of the the same class over various modules, and in fact also over various applications/libraries.
In .NET, this is not more possible so easily, since a class needs to be kept together between a "class" and a "end class" statement.
If you wish to have methods of the same class distributed over several source files, you need to tell that to the compiler using the "partial" keyword.
Wolfgang

BiggyRat wrote: use it for the EXIT button on the main menu of one of my apps

Hm. "Button" on "Menu"? Do you talk about a toolbar-icon?
Regardless which UI you use, for using a menu it has to sit on a form, either you have a shell as in VO, or at least a Form, which holds the menu.

Re. the locked problem: I take it you use Xide, so, is the "check for running" option Chris mentioned set, or not? Mine is, and i always get reminded when i forgot to close the app - and NEVER see the the lock you have.

Hi FFF. The main menu I refer to is a screen I designed and called it Main Menu. Something I notice seems to be a class of the same name in X#. If your familiar with the old ACCESS database .net programming, Microsoft called the same screen the "Switchboard"

Hi Jeff,

BiggyRat wrote:The main menu I refer to is a screen I designed and called it Main Menu. Something I notice seems to be a class of the same name in X#. If your familiar with the old ACCESS database .net programming, Microsoft called the same screen the "Switchboard"

Hmmm, reading again your message, a screen(window) called Main Menu? Do you mean a Menu on the MainScreen called Main Menu?

Again, forget about old terminology. .NET we talk about Forms or WinForm found in System.Windows.Forms.Form. There is actually no difference between "DataWindow" and "MainShellWindow". You just create a Form and have a property to specify it is a MdiContainer and there you go, a "MainShellWindow" created.

Same with a "DataWindow", it is just again a Form or WinForm, you just specify its parent, the Form you created as having the Property IsMdiContainer in layman's terms.

We don't use Menu anymore, use the MenuStrip, ToolStrip and StatusStrip

Just google the above and you will find the implementation on the Microsoft MSDN website.

Also you need to get grips with Referenced Assemblies, NameSpaces and USING. If you don't understand that it will be a lengthy and bumpy ride till you grasp that concept.

Let us know where you still battling.

Johan,
nope, i think he made a form to place buttons on it. Did similiar, albeit on regular forms, in Vo times, because button's actions were easier to grasp than modifying menus

Karl

Jeff, first please explain exactly what you are doing. How did you create your app, did you use the VO-compatible Mdi template? So you have a ShellWindow, DataWIndows etc? If yes, then you should be able to use the same exact methods as in VO.

If not, so you are not using any VOSDK classes, but created a WinForms app, then you can forget all the above . If you are gonna use the "new" windows that come with .Net, then you cannot use VOGUI code. The equivalent of VOGUI's QueryClose() in WinForms, is the "Closing" event, you need to react to it. And when you want to display a message, you will need to use a .Net method as well, please have a look at MessageBox.Show():

https://docs.microsoft.com/en-us/dotnet ... geBox.Show

I think people are missing my point. please see the attached files. It should make it very clear (I hope). The code as I said above was written in VO as you will see in the attached screenshots

Jeff,
sorry to say, but you write lousy bugreports.
Did you try to view your attachments?
Anyway: If this is VO, your "Main Menu" is simply a dialogwindow with buttons on it? As in the Basic dialog sample? Do you want to continue with the "VO" window?
If so, go to the form, click on it, in the properties pane, tab WindowsEvents there's your Queryclose. Doubleclick the "..." and the code is there. Nothing changed re VO

Karl