Hi there,

I'm still fairly new to programming. Would someone be able to explain exactly how different windows should be used in MS Visual Studio?

It seems that variable sharing between different windows is problematic. So does that mean that if you are trying to do multiple things on one window, you should construct each thing dynamically?

An example. I have a window with a listbox containing a list of images. When I click, the selected image populates a larger image box. I want this image to go full screen when I click F5.

At the moment I telling the current window to launch a different window at fullscreen. But would a better way involve dynamically reconstructing the current window to display fullscreen?

It seems that variable sharing between different windows is problematic.

This is not true! Perhaps it is not easy or obvious, but it certainly is not problematic.
Look here how I tested parameter passing between two forms(windows).
The essence is you got to have a public field in the second form where you can pass anything from the first form.

That is ok for a simple case. If you have multiple windows that may be called in various sequences, and complex data to be shared, then the standard approach is to create a new class that holds all the data and make that class available to all windows.

commented: True indeed. +15
commented: Right solution +6

Agreed with @JamesCherrill.
Using a class object you can do it easily.

And there's more!
Your data class can raise events whenever it's data changes and your windows can have handlers/listeners for those events so that when one window changes the data all the others can automatically update themselves. Amaze your friends.

I'd also be sure all my windows/forms are running in the same thread, else race conditions might also become an issue to deal with.

Good point. In Java all gui activity is serialised on a single thread, but I don't know aboutC#.
If it is a problem then the simplest solution is probably to force the data class updates to happen serially by locking its update methods on a single lock object. More complex problems such as two windows performing incremental updates or concurrent input to the same items are probably a symptom of a UI design issue because no matter what you do the user is going to confused or disappointed. Much as I try to avoid modal windows, there's a lot to be said for making some input forms modal with respect to any other windows that can update the same items.

@James could you elaborate on why you try to avoid modal windows? I just think they can be very useful.

It's an old Apple thing - modal means the computer is telling the user what they can or can't do, whereas, as far as is possible, the user should be telling the computer what they want, whenever they want.
That, if course, is a fantasy about some ideal thing that we don't know how to do yet, so in reality modals are often necessary and frequently useful.
J
:)

Thanks guys for your awesome responses! That makes a lot of sense.

Though what is a modal window, is it different from a form?

A modal window is one that interrups your nornal operating of application/s. It needs your attention before it will give back focus to it's parent.

They can be annoying when they are a child of the desktop window and stop you from doing anything at all until you respond to its demands.

Oh right, yeah those are always annoying haha.

It's an old Apple thing

I know, I worked and programmed with a Macintosh in the previous century. :)
Modal dialogs should be done right, this was not always the case on Windows. Apple had UI rules for that. You always knew beforehand if you would open a modal dialog(window). It was indicated with a 3 point marker called an ellipsis after a command text in a button or menu. A modal dialog should always contain a Cancel and OK button. A good example is Print ... in a menu. The ellipsis tells you a window will be opened, asking for extra information from the user. I know this is more and more becoming old style, if you look at the ribbon UI in Word and Excel, but I kinda like it and it is still used in many applications.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.