Any one see whats wrong with this save setting???

[Johnson]

I recoded how i saved my checkbox setting. my old way works but im trying to code better.

Form exit code

    Private Sub btnExitapplication_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExitapplication.Click
        SaveSettings()
        End
    End Sub

savesetting sub

    Private Sub SaveSettings()
        My.Settings.autoConverturlstoshort = autoConverturlstoshort
    End Sub

    '//Gets or sets a value that indicates whether the application should auto convert urls.
    Public Property autoConverturlstoshort() As Boolean
        Get
            Return EnableAutoConvertToolStripMenuItem.Checked
        End Get
        Set(ByVal value As Boolean)
            EnableAutoConvertToolStripMenuItem.Checked = value
        End Set
    End Property

 

[JohnH]

I don't know what gave you the idea to use End to close the application, but using Close instead will at least allow your app to close properly.

 

[Johnson]

Hi john

i did that as i use

    Private Sub Main_FormClosing(ByVal sender As Object, ByVal e As System.Windows.Forms.FormClosingEventArgs) Handles Me.FormClosing
        '//Hide application to system tray
        e.Cancel = True
        Me.WindowState = FormWindowState.Minimized
    End Sub

so it just goes to tray using close

any ideas?

 

[JohnH]

Lots.

IMO, that is incorrect usage of FormClosing event, though I see it used for applications that can not be closed by user. Remove it and your problem is solved. It is wrong for you to always cancel form closing. It is wrong to minimize the form when user want to close it. The close button is for closing the form, the minimize button is for minimizing the form. Use the Resize event and check WindowState, there you can hide form and show the tray icon.

 

[Johnson]

I changed it, didnt realise end was killing it

thanks j

 

[jmcilhinney]

I can see JohnH's point of view but I have to disagree. The Close button on a form is for closing the form, yes, but if you remove the form from the user's view and display a tray icon in its place then, from the user's point of view, the form is closed. The fact that it still exists doesn't matter from a UI perspective. As far as the user is concerned the form is closed, so the Close button did what it was supposed to do. I would suggest that minimising the window should do only that, leaving the window icon visible in the Task Bar, just like any other minimised window.

That said, if you are going to use that type of code then you have to be careful to only prevent the form closing under specific circumstances, otherwise you'll prevent Windows shutting down. You should test e.CloseReason and only set e.Cancel to True if it's UserClosing. That allows you to call Application.Exit from a tray icon context menu to close the app and it also allows Windows to close the app when shutting down.

 

[JohnH]

Closing the form does not just mean closing the form in its most narrow sense. If it's the applications only form/window then from the users perspective closing it means closing the app, that how HCI has always been. So if the app doesn't close when user tells it to, what have you got? An annoyingly persistent app that doesn't do what user expects. What are they trying to say? "This app is so good you really shouldn't close it" The exception I mentioned first, app that user can't close, is typically UI for resident services like AV for instance, where it makes sense in a weird way that the app 'stays to protect no matter what'. I also see this with some newer regular applications that in some cases may be expected to stay resident, one examples is Spotify where user may be listening to music when "accidentally" closing the window, another is Bittorrent where downloads may be in progress. Users should still be smart enough to decide for themselves if they want to close or mimimize and use the appropriate command interface to do this. I still find it highly annoying, even if I understand why they have implemented this dumbed-down version of attempting to be especially helpful and thinking one step further on the users behalf. If I close the apps only window I do that because I want to close the app, but now I have to relocate to the tray area and search it out (possibly among hidden icons) to find where that apps tray icon is and open its context menu to be able to finally close the app. If these apps at least could be intelligent enough to close when there was no activity and stay resident in tray when there was activity, then perhaps it could be somewhat tolerable, but I'd prefer the close button to work as it is expected to in Windows applications and the minimize button to send to tray or taskbar if that is what user opts for. After some time I actually found a preference option in Bittorrent that defaults to 'close to tray', so at least for this app this "feature" can be turned off, but that should have been 'close to tray if activity', disabled by default IMO

 

[jmcilhinney]

I submit Skype as an example. If I minimise the window I want the form to disappear but the window icon to remain in the Task Bar so that I can access it quickly when I need it again. If I close the window then I want the window and the Task Bar icon to disappear, but it's a very rare thing that I actually want to close Skype because then I can't receive calls from my contacts. Closing the window closes the window, but the app is still running in the background and that is evidenced by the fact that there's a Skype icon in the tray.

Obviously an app should document this behaviour and, in almost all cases, provide a way to turn this behaviour off, but I have to say that I consider it perfectly logical behaviour for a lot of applications. If the default bahaviour of the Minimize button was to minimise to the tray that that would be annoying to me, because minimise means minimise to the Task Bar. Again, if an app provides the option to choose then that's fine, but to say that minimising to the tray is any more logical or normal than closing to the tray is, in my opinion, wrong.

It's important to keep in mind that an icon in the task bar is NOT supposed to represent a window, so treating it like it does isn't appropriate. It's the icon on the Task Bar that represents a window. If you close the window then that icon should disappear, and "closing to the tray" accomplishes that.

 

[JohnH]

Well, we can agree to disagree. From my pov such feature is just a redirection of "user closed but really meant minimize". I can't see how you think the tray icon doesn't represent a window when that is its exact dependency in the first place, the tray icon is just a hook to an existing window handle (visible or hidden). The notification area (tray) is also just a part of the Taskbar, where the task buttons represent windows (in any WindowState), so either way the window is linked to the taskbar. Whether the window is minimized to a button or an icon makes no difference to me, but I differentiate between something closed or hidden. A closed window certainly can't have a tray icon.

 

[jmcilhinney]

I can't see how you think the tray icon doesn't represent a window when that is its exact dependency in the first place

I don't intend to get into a big argument here but you should remember that what we generally call the "system tray" is actually officially called the "notification area". It's purpose is to notify the user of various happenings. For example, when I receive new email, Outlook displays an envelope icon in the tray. This icon has no specific correspondence to a window; I already have another icon in the tray that represents the Outlook application. The fact that the .NET NotifyIcon component is generally added to a Windows Form in the designer does not mean that the Windows OS considers a tray icon as being specifically representative of a window.

To the OP I will say this: minimising to the tray and closing to the tray are both legitimate behaviours but you should definitely document any such behaviour. Also, except in cases where the user would legitimately expect your app to be running at all times, such behaviour should probably not be the default, but rather selectable via an Options dialogue.

 

[JohnH]

What I was referring to was the underlying Shell_NotifyIcon API that registers the notify icon based on a window handle. In the old days this was commonly done using the window handle of the apps main form. I see that .Net routes this to a NativeWindow, so technically one could probably get away with an app that runs a message loop and has only a NotifyIcon and no active forms, though it would be unusual, especially for a forms app that has no need to complicate things in this regard.

To cancel FormClosing on CloseReason.UserClosing is a valid approach when "close to tray" option is enabled.

 

[CNC_Man]

I respectfully have to agree with John! Unless, as you stated I'm being notified of such behavior.

 

[jmcilhinney]

I respectfully have to agree with John! Unless, as you stated I'm being notified of such behavior.

I seem to recall posting that such behaviour should always be documented and generally only enabled by user options. I certainly didn't, and wouldn't, suggest that the user should not be notified of such behaviour, so you're respectfully agreeing with me too. Then again, my name is John too, so maybe you were agreeing with me anyway.

 

[Johnson]

Wow. thanks for all the valid points guys. I agree with you both.

I think as long as the user has an option to turn off such a feature then its acceptable. Out of habbit i always hit the X (close on a window)

Thunderbird is running all the time, so i would find my self getting very annoyed because i kept ending the process. so i have the option to close thunderbird to tray.