Show Dialog from a hidden form.

[stepdragon]

I'm trying to create a program that will look at a website and check it for updates, similar to an RSS feed. It then will show a dialog (Form2) that will inform the user that there is an update.

Form1 is used as the configuration form and is able to be shown via a notify icon in the system tray, which is on Form1.

Originally I would have Form1 hidden via Me.Hide() and then run a timer which would check for the updates and call Form2.ShowDialog() when there's an update, I found out however, that if Form1 is hidden, the dialog will not show.

Next I tried not Hiding the form, but instead setting its ShowinTaskbar property to False. At this point the program functions correctly, however when I minimize Form1 it sits in a shrunken window near the task bar...

Is there any way to completely hide Form1 (when minimized), and allow Form2 to be shown as a dialog?

I hope I described my problem well enough. Please ask for clarification on anything.

[jmcilhinney]

You don't need to hide Form1 at all. Just don't create it at all except when it's needed. The same goes for Form2 and any other forms. Follow the CodeBank link in my signature and check out my Formless Tray App thread.

[stepdragon]

I'm using Form1 for other things, I do need it loaded.

For example:

Form1 hold the timer checking updates
I'm constantly adding complex entries to a listview on Form1
Other weird stuff that I don't want to recode

There's always a better way to do anything, but given the way my program is already laid out, is there a way to show a dialog from a hidden (yet active) form?

[jmcilhinney]

You don't need the form to use the Timer. The Timer can be added to the ApplicationContext, just as the NotifyIcon is in my example. It would probably make more sense to use a Timers.Timer rather than a Windows.Forms.Timer anyway, because your update checking should probably be done on a secondary thread.

[jmcilhinney]

As for your issue, I just tested and displaying a modal dialogue from a hidden form worked fine for me.

[stepdragon]

All I know is it doesn't work for me... Did you launch a form using X.ShowDialog(), from a timer (just to check)

and its nice to know there are other ways to time things, but I am also doing other things on the form.

Code wise all I have is basically a timer on form1 with an interval of 5 minutes, which on tick (checks a boolean to see if it needs displayed) and then calls Form2.ShowDialog().

Also FYI I have Me.Topmost=true under Form2_Load() because I needed it to be noticable at any time (and sometimes it wouldn't show topmost if I was actively using another program)

[stepdragon]

Hmmm I just tested it in a blank VB project and it did work... I wonder what's causing it not to trigger? Whatever i'll go through the code and debug it later... I'm working on changing some of the main code to be cleaner anyways... I just didn't want to start into something big when there was major functionality problems... but its probably just not triggering correctly or something.

Thanks for Pointing out my ignorance / enlightening me on other timing possibilities

[jmcilhinney]

All I know is it doesn't work for me... Did you launch a form using X.ShowDialog(), from a timer (just to check)

Yes I did.

and its nice to know there are other ways to time things, but I am also doing other things on the form.

A form is for interacting with the user. If your code is not for interacting with the user then it shouldn't be in the form, whether the form is hidden or not.

Code wise all I have is basically a timer on form1 with an interval of 5 minutes, which on tick (checks a boolean to see if it needs displayed) and then calls Form2.ShowDialog().

If a main form is the focal point of your app then it makes sense to have the Timer in that main form, although the code it invokes should be elsewhere if it doesn't relate directly to user interaction. If the form is not the focal point of your app, which it isn't if it's usually hidden, then it shouldn't contain the Timer either.

Also FYI I have Me.Topmost=true under Form2_Load() because I needed it to be noticable at any time (and sometimes it wouldn't show topmost if I was actively using another program)

Why would you set TopMost in code when you can set it in the designer? It sounds to me like a balloon tip on the NotifyIcon would be a more appropriate notification. The user can then click that balloon to open the dialogue.

[stepdragon]

I'm not blindly coding, I do have reasons for the layout of the program and the dialog. One of the reasons for the dialog is to have a persistent notification that will not go away until the user acknowledges it. For example, if you're looking for updates that happened overnight, you will see the dialog in the morning. In addition, it can show content from the update in a chosen layout rather than a single text bubble.

I also have reasons for the timer configuration, but given your logic on user interaction I have to agree that using a timer on a separate thread / container would make more sense. I do not know how to do that just now but I am researching it because of your suggestion. If you would like to leave an example it would be appreciated.

Why would you set TopMost in code when you can set it in the designer?

Because I didn't know it was in the designer

(Did I mention that I self taught myself VB3 10 years ago and I made the Transition to .Net with no supervision?)

[jmcilhinney]

I'm not blindly coding, I do have reasons for the layout of the program and the dialog. One of the reasons for the dialog is to have a persistent notification that will not go away until the user acknowledges it. For example, if you're looking for updates that happened overnight, you will see the dialog in the morning. In addition, it can show content from the update in a chosen layout rather than a single text bubble.

A balloon tip on a NotifyIcon is far less intrusive than a TopMost form, which could pop up over another window that the user is currently using. Why do you think so many applications use system tray balloons or so called "toast" windows? Because they are unobtrusive while still being informative. You can easily use a balloon or toast window in your case and achieve the same results, with the user choosing to view the data if they want to, rather than having it shoved in their face.

(Did I mention that I self taught myself VB3 10 years ago and I made the Transition to .Net with no supervision?)

I'm not a self-taught programmer but I taught myself VB.NET too, with no prior VB experience. I have done a lot of things the "wrong" way over the years, as everyone does. You just need to be able to adjust when you are presented with a better option.

[stepdragon]

A balloon tip on a NotifyIcon is far less intrusive than a TopMost form, which could pop up over another window that the user is currently using. Why do you think so many applications use system tray balloons or so called "toast" windows?

The user base for this program is quite limited... to the point where I don't think they'll mind if they're interrupted (user base is me)

joking aside, this program is designed to interrupt you. think of it like an alarm clock, you don't want a nudge when you're asleep, you want it to blaze loudly and shake you awake...

however, once again, you do make a good point, and if I was making a similar program for a wider audience I would focus on that aspect more. Do you know a good example of a "Toast" window? which can include dynamically formatted text, pictures, and multiple choices? (go to folder, to to website, dismiss)

When I mentioned self teaching VB there was something else I didn't mention. When I worked with VB3, I didn't have internet access, so I had no training there. Next I moved on to VB5 (not 6) and applicable code snippets were nearly impossible to find, because every tutorial was using VB6, so I was still on my own. finally when I migrated to .NET there was a community to rely on, but I already had practices that I used in 3 and 5, and although they aren't the most efficient ways of doing things now, they were more acceptable back in the day. I don't dismiss new ideas, and I don't not look for ways to do things, but if I already 'know' how to do something the 'old way', I have no reason to try to find out if there is a 'new way' of doing things, until someone like yourself tells me that there is a better way.

I hope that clears the waters a bit.

[jmcilhinney]

If you're determined to stick with your current design then all I can tell you is that it worked for me. I suggest that you do what I did and what you should always do in situations like this: create a new project and add only what is absolutely required to test the functionality you're having trouble with. If it works then you know that it's something else specific to your original project that is the issue. One option then is to start adding other functionality to your test project to make it more like your original project and, when it breaks, you've found the culprit.