Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages'
Application with multiple 'pages' Application with multiple 'pages'
Application with multiple 'pages'
Go Back  Xtreme Visual Basic Talk > > > Application with multiple 'pages'


Reply
 
Thread Tools Display Modes
  #1  
Old 08-06-2012, 06:22 PM
digitalBCP digitalBCP is offline
Newcomer
 
Join Date: Aug 2012
Posts: 2
Default Application with multiple 'pages'


Visual Basic 2008

I am developing an application and am trying to implement multiple pages within one single form (I don't like the look of forms opening and closing since its very noticeable).

What are the best ways to implement this successfully? I have tried using UserControls and a MDIParent Form. I have had fairly good success with UserControls but am not sure how efficient it is.

As far as the MDI-parent form iv been struggling with two big factors. One being when I have three child forms within the parent I have no idea how to access one child form from another. To explain the second issue let me first off state that all my forms are borderless without a task bar. With that being said when I open a child form I can see the task bar flash very quick when the form initializes. This isn't a major issue but enough to make the UI lacking when this application is for a company.

Now if UserControls is the most efficient how do I share information between each other such as variables? I have also provided a screenshot of part of the program displaying three child forms that need to be able to interact with one another.

Any information regarding this issue would be extremely helpful and appreciated!
Attached Images
File Type: png Untitled-3.png (203.4 KB, 16 views)
Reply With Quote
  #2  
Old 08-07-2012, 01:41 PM
AtmaWeapon's Avatar
AtmaWeaponApplication with multiple 'pages' AtmaWeapon is offline
Fabulous Florist

Forum Leader
* Guru *
 
Join Date: Feb 2004
Location: Austin, TX
Posts: 9,500
Default

The answer is simple if you've done it and understand it but complex if you're just starting at it.

The "right" way to go about it would be to go read some articles about Presentation Model patterns; MVC is common in WinForms and they usually use MVVM in WPF. But if you're struggling with "How do I share information between UserControls?" you need to start smaller.

It makes me really sad that no one really teaches dependency management because it's often a harder problem than writing the rest of the program. It's something you're supposed to just figure out and it's actually very tricky. Here's a mini-tutorial in an informal style. It's going to sneakily teach you what Presentation Model patterns are all about while it's at it.

Think about classes in your program like you would little boxes with machinery inside. Consider a radio. It's got a knob for tuning that determines the station and a knob for the volume. It's also got a button for turning it on and off. We can represent it in code like this:

Code:
Class Radio
    Public Property Station As Double
    Public Property Volume As Double

    Public Sub TurnOn()

    Public Sub TurnOff()
End Class
Think about how you tell the radio what to do. You can turn the volume knob, turn the tuner knob, or push the power button. You can imagine what a form for this might look like (pretending that there's a knob control available.) But... normally you're taught to throw everything into a form. that is to say, most people would write code like this:
Code:
Class Form1 
    Inherits Form

    Private _volume As Double
    ...

    Sub VolumeKnob_ValueChanged(...) Handles VolumeKnob.ValueChanged
        _volume = VolumeKnob.Value
    End Sub
End Class
That's how most WinForms code's written; you've got a variable to represent a control and you sync it with the control property. Most people forego the variable and just use the control property directly. I call this the "ball of mud" development style because all of the code is glommed into a few really big files. Why's this bad? Let's get back to it.

What's happening there is Form1 isn't representing a radio. Form1 is a radio. It sounds like a subtle difference until Form2 needs to have a radio too. Oops; your only option is copy and paste. So it's better to use that Radio class from earlier:
Code:
Class Form1 
    Inherits Form

    Private _radio as New Radio()
    ...

    Sub VolumeKnob_ValueChanged(...) Handles VolumeKnob.ValueChanged
        _radio.Volume = VolumeKnob.Value
    End Sub
End Class
Now Form1 has a radio, and the knobs manipulate the radio. If Form2 wants a radio, it can create one. Or it can get Form1's. Say you want Form1 to be able to open a Form2 that shares the same radio. Here's one way to design Form2 to facilitate that:
Code:
Class Form2
    Inherits Form

    Public Property Radio As Radio
End Class
For it to share Form1's radio, Form1 can set the Radio property:
Code:
' (In Form1:)
Sub ShowOtherForm()
    Dim frm As New Form2()
    frm.Radio = _radio
    frm.Show()
End Sub
Taking it further, maybe 10 controls want to share the same Radio. It might be inconvenient for it to be a private detail of Form1. In applications like that, you might have some more global class that keeps track of the radio. The business of "Who owns each object, and how do the things that need those objects get them?" is called "dependency management". It's probably one of the most important factors in software development, and screwing it up is what leads to programs that are hard to maintain.

In short, these are the things that make up practically all modern application development methodologies:
  • You should strive to make small classes that do one thing.
  • Gluing several small classes together is the right way to do multiple things in one class.
  • Classes communicate with each other via properties and method calls; usually passing other classes to each other.
  • Figuring out who owns what class and how they communicate is the hardest part of a large application, and screwing it up will cause you no end of grief.
To make it relevant to your question:

To make an application like that, I'd make some kind of "Page" base class to represent a control that can go in a pane of the application. Each control would expect to get fed some information and it would display that information; if it was supposed to give information back it'd do that in a standard format. I would not want Control A asking Control B for values; I'd rather Control A ask some overseer that happens to know about Control B. That way, when I want to remove Control B 6 weeks from now things are cleaner.
__________________
.NET Resources
My FAQ threads | Tutor's Corner | Code Library
I would bet money 2/3 of .NET questions are already answered in one of these three places.
Reply With Quote
  #3  
Old 08-07-2012, 05:34 PM
digitalBCP digitalBCP is offline
Newcomer
 
Join Date: Aug 2012
Posts: 2
Default

Thank you very much for such an informational post. Although I thought I was fairly experienced in VB this completly turned that around for me. Not that its a bad thing I just am going to need to study up on this to know how to do it efficiently and effective.

So for example if I am to implement this method what would I put those three pages that are in my screenshot in? Not a userControl or separate form?
Reply With Quote
  #4  
Old 08-07-2012, 06:41 PM
hDC_0Application with multiple 'pages' hDC_0 is offline
Contributor

* Expert *
 
Join Date: Feb 2004
Posts: 559
Default Moving away from MDI (multiple document interface) towards some kind of TDI

Did you know that there is something called an mdi file?
It was part of the MODI removed in Office 2010.

I just thought I would bring that up for disambiguation reasons.
The acronym MDI can actually stand for many things, although it's probably clear from your context that it stands for multiple document interface.

Did you know that Microsoft has been moving away from (deprecating)
the multiple document interface for some time now in favor of a TDI (tabbed document interface).

The first clue comes with this MSDN page for the Multiple Document Interface which says:
Quote:
Many new and intermediate users find it difficult to learn to use MDI applications. Therefore, you should consider other models for your user interface
Many of the difficulties of the MDI interface are detailed on the Wikipedia page for Multiple Document Interface:
Quote:
Disadvantages
-Can be tricky to implement on desktops using multiple monitors as the parent window may need to span two or more monitors, hiding sections.
-Virtual desktops cannot be spanned by children of the MDI. However, in some cases, this is solvable by initiating another parent window; this is the case in Opera and Chrome, for example, which allows tabs/child windows to be dragged outside of the parent window to start their own parent window. In other cases, each child window is also a parent window, forming a new, "virtual" MDI [1].
-MDI can make it more difficult to work with several applications at once, by restricting the ways in which windows from multiple applications can be arranged together without obscuring each other.
-The shared menu might change, which may cause confusion to some users.
-MDI child windows behave differently from those in single document interface applications, requiring users to learn two subtly different windowing concepts. Similarly, the MDI parent window behaves like the desktop in many respects, but has enough differences to confuse some users.
-Deeply nested, branching hierarchies of child windows can be confusing.
-Many window managers have built-in support for manipulating groups of separate windows, which is typically more flexible than MDI in that windows can be grouped and un-grouped arbitrarily. A typical policy is to group automatically windows that belong to the same application. This arguably makes MDI redundant by providing a solution to the same problem.
-Controls and hotkeys learned for the MDI application may not apply to others, whereas with an advanced Window Manager, more behavior and user preference settings are shared across client applications on the same system
-Modularity: An advanced window manager can be upgraded independently of the applications
Some quotes from across the internet
(indicating that some people are getting the idea
that Microsoft's support of MDI is not as strong as it used to be):
..from this vbAccelerator page:
Quote:
Over the years, Microsoft applications have been moving away from the old Multiple Document Interface style..
..from this page:
Quote:
One important new feature of Excel 2013 is that it no longer supports MDI (Multiple Document Interface)
and it now uses the SDI (Single Document Interface) paradigm, just following a trend that other Office applications, like Word, started a few years ago.
..from this page:
Quote:
We are mercifully moving away from the days where people thought floating palettes and child windows were a good idea.
Microsoft dumped the multiple document interface (MDI) several years ago and Macromedia has dumped floating pallets in favor of docked panels in most of it’s apps and this brings a modest improvement.
..from this page:
Quote:
By default, versions of Word that are later than Microsoft Word 97 use the Single Document Interface (SDI) design,
in which each document occupies its own window
(just as in Microsoft Outlook each message occupies its own window).
This behavior is different from Word 97 and earlier versions of Word,
which use the Multiple Document Interface (MDI),
in which each document is a separate window within the Word program window.
SDI was introduced in Word 2000.
..from this Microsoft Channel 9 page (selected excerpts):
Quote:
MDI as an interface paradigm is old-hat which is probably why there's no support for MDI-like interfaces in WPF as standard. You could roll your own, but it's a bunch of effort just to make your app look old-fashioned. Tabbed interfaces like you see in most apps now, including Visual Studio, are the way to go, and almost trivial to set up in WPF.

You know I have to wonder: what was so crazy - great - awesome about MDI in the first place.
I can think of a few places where I would still possibly use it but not so many really.
MDI started when the whole "Windows can multitask, here this will SHOW you that it does" phase was happening (windows 3.1x to windows 95 really)
in most cases users are trying to complete a "task" and what they need to see and work with are the things that get that task done.
so that begs the question: what task needs multiple windows open to do?
why?
I tend to think that in say 99% of all cases you can design the workflow and UI to do it with one dialog, if there are logical "steps" in the "task" then a "wizard" style dialog is the right design.
..the fix was better technically and better UX.
I could go on but you get the idea.

"Dumped" is probably too strong a word but if you look at the direction that
Microsoft is going with Office apps that is the strongest indication to me
that, internally, Microsoft is moving in a different direction.

I like the "fake" MDI (that is really a TDI) provided by the VS.Net IDE.
This seems a reasonable "bridging" compromise but having looked at the
"guts" of the IDE (the Automation and Extensibility model as it is known),
I know it was not easy for the Microsoft .Net IDE development team to implement.

I personally do not like the tab control (either in VB6 or .Net)
The VB6 version always had re-sizing and re-parenting/re-positioning issues.
The .Net version doesn't allow enough customization options.

Quote:
Originally Posted by AtmaWeapon
To make an application like that, I'd make some kind of "Page" base class to represent a control that can go in a pane of the application
I think AW has the heart of it.
Use controls in place of "documents" (hopefully make good use of classes as well).

This has been discussed before (in post #8 onward in this thread),
and surfR2911 was kind enough to make a simple example of a tabbed interface made from panels attached to this post.

A well thought out implementation where panels-as-tabs are "spawned" (instantiated) from a class would be an interesting,
(and probably quite flexible), programmatically (runtime) generated interface.

Last edited by hDC_0; 08-07-2012 at 06:48 PM.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages' Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages' Application with multiple 'pages'
Application with multiple 'pages'
Application with multiple 'pages'
 
Application with multiple 'pages'
Application with multiple 'pages'
 
-->