[MFKJ]

only want the user to be allowed to open one instance at any time.
I want to restrict my form please help.
as i click my button another (Same)form show, show show show

i know showdialogue() method please tell me another way

[tlhIn`toq]

When you open the form you can set the button.Enabled to false.
When the form closes it raises an event saying "i'm done". When your main program hears that event it can re-enable the button.

Quick and easy custom events

Q: ...get Form/class 'A' to make a change or talk to Form/class 'B'
NOTE: Don't try to access GUI controls across forms. Its wrong. Nobody will hire you if you do this sort of crap. It violates every guideline for 'black box' programming, Separation of Responsibility, loose binding of components, and event driven programming. Read the tutorials and learn to do it right the first time so you don't develop bad habits that you just have to un-learn later.
A:

• See this thread for the simplest of example code between two forms.
  
  The tutorials below actually teach and explain it further.
  
• Passing values between forms/classes
  
• Bulding an application - Part 1
  
• Building an application - Part 2
  
• Quick and easy custom events
  
• Delegates, Lambdas and Events
  
• http://www.codeproje...g-Windows-Forms

This post has been edited by tlhIn`toq: 20 January 2013 - 07:28 AM

[andrewsw]

I like the disabling of the button: it's clean, unobtrusive, and follows the good design principles that tlhIn`toq illuminates.

I'm curious, however, about the argument against the following code:

        private void button3_Click(object sender, EventArgs e) {
            bool blnOpen = false;
            foreach (Form frm in Application.OpenForms) {
                if (frm is Form2) {
                    MessageBox.Show("The 2nd form is already open");
                    blnOpen = true;
                    break;
                }
            }
            if (!blnOpen) {
                (new Form2()).Show();
            }
        }

I realise that I'm opening myself up to criticism! I'm not necessarily offering this as a solution, I'm just curious about the argument against it.

This post has been edited by tlhIn`toq: 20 January 2013 - 08:38 AM
Reason for edit:: [member='tlhintoq'] tag fixed

[Tanira]

Hello,

Technically that approach is fine.

The only reasons I have against it is that it would force the users to close the new dialog box adding another step to their process. Granted they should learn after the first time that this is the case and will be unlikely to repeat their mistake. However, it could even lead to requests to make it functionally possible in the future to open more than one at once because once a user sees that something is possible they are always more likely to request new functionality.

But I would say the biggest reason is disabling the button is generally considered to be common practice and for a user interface common practice is the best way to give the user a seamless experience between different applications. The user shouldn't have to learn the application. The application should be designed in a way that the user knows what they can and can't do intuitively.

Eric A Hill

Edited -
The only case I've seen this not be the case is when submitting a form. Usually for form submissions the submit button is always enabled regardless if there are errors on the form. In a way this makes sense because the user is always able to send a request to submit the form. Whether the form will be processed or not is up to the validation in place.

andrewsw, on 20 January 2013 - 08:15 AM, said:

I like the disabling of the button: it's clean, unobtrusive, and follows the good design principles that http://www.dreaminco...89009-tlhintoq/ illuminates.

I'm curious, however, about the argument against the following code:

        private void button3_Click(object sender, EventArgs e) {
            bool blnOpen = false;
            foreach (Form frm in Application.OpenForms) {
                if (frm is Form2) {
                    MessageBox.Show("The 2nd form is already open");
                    blnOpen = true;
                    break;
                }
            }
            if (!blnOpen) {
                (new Form2()).Show();
            }
        }

I realise that I'm opening myself up to criticism! I'm not necessarily offering this as a solution, I'm just curious about the argument against it.

This post has been edited by Tanira: 20 January 2013 - 08:45 AM

[tlhIn`toq]

andrewsw do you mean this part
if (frm is Form2)

I'm not sure of that myself. I'd be checking the type. I think what the OP has here is checking instances.

if (frm.GetType() == TypeOf(Form2))
{
  MessageBox.Show("A Form2 instance is already open");
}

[Tanira]

From my knowledge of how the is command works it should function the same as the code you wrote.
It just looks a bit cleaner.

tlhIn`toq, on 20 January 2013 - 08:41 AM, said:

andrewsw do you mean this part
if (frm is Form2)

I'm not sure of that myself. I'd be checking the type. I think what the OP has here is checking instances.

if (frm.GetType() == TypeOf(Form2))
{
  MessageBox.Show("A Form2 instance is already open");
}

[Ryano121]

Yes in that case it will function exactly the same. The difference between using GetType comparisons is that it will only return true when the types are exactly the same.

In comparison the 'is' operator will return true if the right operand is of any base class or is the same ast he left hand side. e.g -

if(form2Object is Form) // will return true as Form is a base class of the form2 object

But the underlying point is that we really shouldn't be using reflection here. As has already said this is a prime usage of events.

This post has been edited by Ryano121: 20 January 2013 - 08:55 AM

[andrewsw]

Quote

The only reasons I have against it is that it would force the users to close the new dialog box adding another step to their process.

Of course, the MessageBox is only for my demo. More typically, the computer might beep , or just do nothing, or perhaps just set the focus back to the 2nd form.

If you are talking about a web-form submission then I believe that is a different circumstance, due to the web's lack of state.

@http://www.dreamincode.net/forums/user/389009-tlhintoq/

Quote

I'm not sure of that myself. I'd be checking the type. I think what the OP has here is checking instances.

I don't quite follow. (frm is Form2) is checking the Type of each instance(?).

Ryano121

Quote

But the underlying point is that we really shouldn't be using reflection here. As has already said this is a prime usage of events.

Can you explain why my suggestion shouldn't be used?

[tlhIn`toq]

Ryano121, on 20 January 2013 - 09:52 AM, said:

The difference between using GetType comparisons is that it will only return true when the types are exactly the same.

Being precise while offering exact operation is always my goal. I wouldn't want the function to be general. If I had a summary form open, then wanted to open the 'CallHistory" window... then open the "Edit customer' window... then open the 'orderhistory' window... The generalize 'is' comparrison won't let me. But with the exact type match I would be allowed to open a one instance of each of these, but wouldn't be able to open a second copy of the 'orderhistory' for example.

To me, that seems like the behavior a user expects. But I could be making too many assumptions about the OP's intent and application.

[Ryano121]

I'm not sure what you mean by the is operator would not allow you to accomplish that. After all is is just a strict version of the GetType you are doing already.

if(frm.GetType() == typeof(OrderHistoryForm))

if(frm is OrderHistoryForm)

would result in exactly the same thing. I'm not sure how you would not be able to check if an existing form is open using the is operator. That being said I agree that GetType would probably be better in this case, but you still can use 'is'.

Quote

Can you explain why my suggestion shouldn't be used?

It's just a lot messier than the event based solution. In my opinion you should only use reflection when absolutely necessary. It can get slow and can be a bit of a nightmare when you have loads of type checks flying about all over the place. If you needed to check whether a few forms are already open, the solution gets hectic quickly. The event based solution however maintains scalability.

This post has been edited by Ryano121: 20 January 2013 - 09:11 AM

[CodingSup3rnatur@l-360]

In terms of reacting to a closed event of the second form vs your solution, andrewsw, you could argue the form should not really have to know about every other open form. It's not really the form's responsibility to explicitly have to determine if another form in the application is open or not. With the events based example, the form is being told when something happens, rather than having to find out by itself.

The form should only be concerned with updating and retrieving input from it's controls. The events based version allows the form to remain focused on this responsibility.

Also, although it's blindingly obviously what your code is doing to anyone who knows C#, it's arguably not quite as clear, and simple to read as the events example would be. The events example need only be four simple lines of code of straight line code.

Further, I guess there is a potential for error in your example if you changed the form which was being opened by that button. There is a chance you could update the line with .Show(), but forget to update the type check a few lines above. There is duplication there.

Finally, I always view OO code that feels the need to explicitly check types with a certain amount of suspicion. It can get error prone, and as the program grows, and more types are required, you can quickly get into a mess.

EDIT 2: Also, I advocate preventing the user from clicking a button, rather than letting them click the button, only to find out the action they want to perform isn't available after all. The events based solution allows me to implement this.

Having said all that, you could get around many of those issues by moving the code around a bit, and wrapping the code in a nice self documenting function (although the SRP violation would still exist). So, ultimately, it comes down to the fact that the events example is just a cleaner, and more flexible way of achieving this task.

This post has been edited by CodingSup3rnatur@l-360: 20 January 2013 - 09:48 AM
Reason for edit:: Changed Closing to Closed.

[tlhIn`toq]

And just to show there are as many ways to solve a problem as there are coders to ask...

If you premake these forms/palettes you want to open at a class-scope level you can then just show/hide instead of creating new ones.

public class MyMainWindow : Form
{

   private CustomerOrderHistoryPallet OrderHistory = new CustomerHistoryPallet();
   private CustomerCallHistoryPallet CallHistory = new CustomerCallHistoryPallet();
   // blah blah

   void btnToggleCallHistory_Click(object sender, eventargs e)
   {
      CallHistory.Visible = !CallHistory.Visible;
   }
}

This brings us back to Event Driven design as the pallets would then raise events like

.NewCallLogged
.CustomerInfoUpdated
.AccountClosed

[andrewsw]

Thank you CodingSup3rnatur@l-360 and Ryano121

I appreciate the points made about adding additional requirements (complexity).. at a future point.

This post has been edited by tlhIn`toq: 20 January 2013 - 09:53 AM
Reason for edit:: [member='CodingSup3rnatur@l-360']

[andrewsw]

I suppose if the forms were data-bound then we might not bind them until they are displayed, otherwise it might slow the application unnecessarily (if they are never shown).

In this case, would you allow C# to tidy up on exiting the application or would you specifically close all these forms on exit? [Sorry, slightly off topic..]

This post has been edited by tlhIn`toq: 20 January 2013 - 09:52 AM

[tlhIn`toq]

Just an FYI... The way to make a link to a member without making a link to their page is with the member tag

left bracket
member='username'
right bracket

no closing tag

[
member='tlhin`toq'
]

but all together (I can't do it here or the parser will try to parse it

This post has been edited by tlhIn`toq: 20 January 2013 - 09:54 AM
Reason for edit:: [member='tlhin`toq']