Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Add Option To _SCREEN OS Menu

Status
Not open for further replies.

Julio_MGM

Programmer
Dec 12, 2018
15
PT
Hi everyone.

I am trying to add one option to my app System Menu, the menu that appears when you right-click on the tittle bar or you click on the icon.

Is it possible?

controlpanel1_h3bv5o.gif


Thanks
 
i have found it in VB.NET but i don't know if it is possible change the code to VFP.

Code:
Imports System.Windows.Forms
Imports System.Runtime.InteropServices

Public Class CustomForm
    Inherits Form
    ' P/Invoke constants
    Private Const WM_SYSCOMMAND As Integer = &H112
    Private Const MF_STRING As Integer = &H0
    Private Const MF_SEPARATOR As Integer = &H800

    ' P/Invoke declarations
    <DllImport("user32.dll", CharSet := CharSet.Auto, SetLastError := True)> _
    Private Shared Function GetSystemMenu(hWnd As IntPtr, bRevert As Boolean) As IntPtr
    End Function

    <DllImport("user32.dll", CharSet := CharSet.Auto, SetLastError := True)> _
    Private Shared Function AppendMenu(hMenu As IntPtr, uFlags As Integer, uIDNewItem As Integer, lpNewItem As String) As Boolean
    End Function

    <DllImport("user32.dll", CharSet := CharSet.Auto, SetLastError := True)> _
    Private Shared Function InsertMenu(hMenu As IntPtr, uPosition As Integer, uFlags As Integer, uIDNewItem As Integer, lpNewItem As String) As Boolean
    End Function


    ' ID for the About item on the system menu
    Private SYSMENU_ABOUT_ID As Integer = &H1

    Public Sub New()
    End Sub

    Protected Overrides Sub OnHandleCreated(e As EventArgs)
        MyBase.OnHandleCreated(e)

        ' Get a handle to a copy of this form's system (window) menu
        Dim hSysMenu As IntPtr = GetSystemMenu(Me.Handle, False)

        ' Add a separator
        AppendMenu(hSysMenu, MF_SEPARATOR, 0, String.Empty)

        ' Add the About menu item
        AppendMenu(hSysMenu, MF_STRING, SYSMENU_ABOUT_ID, "&About…")
    End Sub

    Protected Overrides Sub WndProc(ByRef m As Message)
        MyBase.WndProc(m)

        ' Test if the About item was selected from the system menu
        If (m.Msg = WM_SYSCOMMAND) AndAlso (CInt(m.WParam) = SYSMENU_ABOUT_ID) Then
            MessageBox.Show("Custom About Dialog")
        End If

    End Sub
End Class
 
What is it you are trying to add?

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
 
Julio,

It seems to me jou want a shortcut menu. Please study the help file on that subject.

Koen
 
You might be able to do things like that with the help of Bindevents(). I don't want to dive into this, though. Look out for an example making use of Windows messages for handling Foxpro Forms without any title bar to have arbitrarily shaped forms or full control about the theme of forms including the title bar.


If you are at that stage, you cannot only design a titlebar as you like, you of course can also create any menu as you like.

I can understand when you want to integrate into the Windows standard to be fully compatible and also stay with the standard in future. It's a better long term working solution, though it also means no full control in apps you'd like to look and feel equally from Win XP to 10. Both needs can be valid.

Anyway, an about dialog there is a mere show off, you'd have that as a menu item in the help menu.

Bye, Olaf.

Olaf Doschke Software Engineering
 
I want to add one new option to the windows system menu, in my app (_screen), the menu that shows when you right click the title bar or when you click the icon on the title bar.

In this case the option i want to add is "Open New Window" and it will launch a new instance of my app.

I am not talking about the forms but the main window itself (_screen)

 
Julio, the System Menu is not the place to put that particular option. The System Menu is part of Windows. Users expect it to contain certain functions relating to the particular window where it appears (Restore, Move, Size, etc.) It is not up to application developers to mess around with that.

Is there any good reason for not putting your "open new window" option in the application's own menus? That's where a user would expect to see it.

By the way, the function itself is easy to implement: you just need to ShellExecute() your own application. I've got exactly the same function in one of my own apps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Julio,
I second what Mike is saying here.
There are lots of options for where you can put this function, and as Mike also said, very easy to implement with a Shellexec() function (you need to add that to your app as well, but it's easy).
Then you just call your application with:

Shellexec(MyApp)

And it will launch another version (where "MyApp" is the name of your .exe)
Does your application utilize the full windows main title bar? Or are you hiding it and implementing your own?

This is also another option. I have actually abandoned the VFP menuing system and title bar, and implemented my own. (It resembles modern ribbon bar). Then in the top left corner of the window, I have placed an icon in the "Title bar" space, which I've replicated. If you do that, then your right click on the application icon can launch your own "popup menu", and you can then replicate all the functinoality of the Windows Popup... but again, I don't recommend this.

Put it as an option in your topline menu (or ribbon), you could simply implement your topline menu with "Launch", and when clicked, it launches your app.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
In Windows 10 it's also a standard for any executable, the context menu of the taskbar icon has the EXE name as the first item and that restarts the same EXE.

I only see Chrome has the menu item to add a new tab, but then I rather use CTRL+T (IIRC other browsers use ALT+N) or the new tab + icon in the title bar.

Bye, Olaf.

Olaf Doschke Software Engineering
 
I am sorry for the delay to answer.

I am running the app in windows remote app so right click is not the way to go.
 
Remote desktop doesn't prevent using a context menu, why shouldn't it apply? The OS windows title bar menu you show also is available with a right click on any point of the title bar, not only with a left click on the left upper icon.

If you go for the idea to make your own title bar, you actually can do both again, as anything is VFP controls then, you can have a left upper icon that's either a VFP image control or button set to flat look with picture and the rest of the titlebar could be a container or another image for whatever bar look you want and its right click can show that menu you are used to by Windows itself.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Regardless of whether or not you can right-click, I would still like to know why you want to use the System menu for this. Why do you not want to use your application's own menu? Or a button somewhere in your interface? Or any other device for invoking the required action?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
From the feature aspect, I can kind of understand this, as starting another instance is just the opposite of quitting the application and the Application quit is also a title bar button, the upper right [X] button.

But indeed also the Quit action is typically a menu item of the File menu: Exit or Quit. And you can set a hotkey, too. You don't need to have this feature in the title bar.

I'd just not really use the title bar menu. Why so complicated, if you could have a menu item with a hotkey? And that menu item could be part of your file menu, for simplicity sake, just like Exit/Quit is.

Even when you don't want your application to have a menu, you can define a shortcut (context) menu without ever making it visible and react to hotkeys defined for its items. That's how you can also keep the usual hotkeys like copy/cut/paste working in applications not using a menu at all, so they don't have a MED_EDIT menu. Besides you can setup up ON KEY.

All these things are much simpler to add without the hassle of Bindevents and API usage, that may need to vary with Windows versions.

Bye, Olaf.

Olaf Doschke Software Engineering
 
There are some option where i disable the menus and all shortcuts, like for example in print preview.

And in that cases if i want to open a new windows its not that easy.

So this way if i am using the system menu it will always work.
 
No, an ON KEY LABEL always works, that's the reason it's often not recommended, because it acts so global.

Besides the easiest way to add any tools you need during report run is take the source code of foxypreviewer and extend it, as it makes use of its own preview window and toolbar.

Nativley it's also possible to make entries ina foxuser.dbf to change the report preview toolbar, but that's much more complicated than basing your reporting on foxypreviewer.

Bye, Olaf.



Olaf Doschke Software Engineering
 
Disabling menus, for example in the print preview window, makes sense. But this is not all or nothing. You can still leave selected menu options, command buttons and hotkeys enabled.

In my apps, I have a modal form class. In its Activate, it disables the main menu, and it re-enables it in its Destroy. I use a ribbon-like toolbar rather than the built-in pull-down menus, but the principle is the same. When it receives a disable request, the ribbon disables most of its controls, but not all of them. In particular, it leaves the Help button enabled, and also controls for copy, cut and paste.

You could do the same. I'm not suggesting that you abandon your existing pull-down menus. But you could for example create a custom toolbar which contains your most common commands. This could include your "open new window" button.

Alternatively, you can simply stipulate that the "open new window" facility won't be available during a print preview. Not much of a hardship, surely?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
I am using foxypreviewer.

I understand the other options but i need to make lots of changes so that they can work.

I have it working.

I can put the link to the forum with the answer but i don't know if it is allowed.
 
You have posted the solution, this is translatable with DECLARE and using BINDEVENTS to Windows messages. I already also pointed to Bereznikers article to handle such messages to move (drag) a form without its native title bar. There also are samples in the VFP solution samples to act on the titlebar.

We tried to convince you to solve your problem with normal and much simpler possibilities of VFP instead of translating your code.

Anyway, then you got what you wanted elsewhere. If that's fine with you, ok.

Bye, Olaf.

Olaf Doschke Software Engineering
 
I am only using this option because of remote app. The way it is working for me (i think) is the best solution.

But i agree with the solutions that were given here. The only problem was the amount of code i need to change to make it.

If i was going to start something, i would go with that options, because in that way i could add more things.

But for now i am going with the solution i was aiming for.

venda_bfuls4.png
 
It's okay, but then I wonder what in your remote app situation hinders right clicks to work? What are you using. Windows Remote Desktop and Terminal Server allow right clicks, Teamviewer allows right clicks, I don't know anything, which doesn't.

And a menu item would also work without right click, even just with keys.

If you don't describe this in your help system, I wouldn't find this, as I don't expect a "new window" ("Nova Janela") option from that window menu. If you had a + icon like Browsers in their tabs, that'd be discoverable UI, yours is a specialty nobody that has experience with Windows expects and anybody that's a mere mortal normal user doesn't even know. So unlike a simple menu of the standard menu or a tool (icon) in a toolbar) this needs extra explaining, that's what's so undesirable about it.

It's your decision, I think we provided all thoughts about this topic and if you still stick to your solution as the best for you, there's nothing that will convince you.

Bye, Olaf.

Olaf Doschke Software Engineering
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top