|
I have an old Windows Forms project that has an annoying habit of claiming (some of) the forms have changed when they haven't. For example, I open the project. I open frmMain.cs, it appears in design mode and is immediately marked as changed (with the * next to the file name) even though I haven't do anything yet. This would be only marginally annoying except several times in the past it's managed to mess up some of the controls on the form (e.g. disappearing toolbars) when I've let it save while closing the project (without thinking about the fact that I didn't actually change anything).
Has anybody else seen something like this? Has anybody else managed to fix this problem?
|
|
|
|
|
Someone's been writing code in the InitializeComponent method.
#region Windows Form Designer generated code
private void InitializeComponent()
{
this.components = new System.ComponentModel.Container();
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.Text = "Form1";
}
"You get that on the big jobs."
|
|
|
|
|
I don't *think* I changed anything in there, but I'll make sure to double check.
|
|
|
|
|
I've seen this too and it is damned annoying! Last week I built a form from scratch and found that the problem occurred when I set the docking property of a MonthCalendar. I didn't pursue that any further as I already knew that the form.cs, .designer.cs and .resx were not changing.
As for stuff disappearing I think you just have to accept that the designer will occasionally get it wrong. I've seen the error message
Code generation for property 'Items' failed. Error was: 'An item with the same key has already been added'
presented on a message box with a nice OK button to click. No it is not OK to remove the items from my toolstrip would be my answer but by then it's too late and usually the line of code that adds the individual items to the container has been deleted.
e.g.
toolStrip1.Items.AddRange(new ToolStripItem[]{....})
I've got a note in the comments on one form that says "WTF - added Load event handler, toolstrip items wiped".
My solution to these designer problems was an automated hourly backup of changed source code. I know that this works as the problem reoccurs only when the backup has failed!
Good luck, Alan.
modified 25-Sep-11 3:42am.
|
|
|
|
|
Wjousts wrote: Has anybody else seen something like this?
Yup. Often in custom controls, someplace setting a property once it's shown. The Designer picks up the change, and marks the document as dirty. Checking the DesignMode[^] would be a quick work-around.
If the form goes dirty, can you undo it?
Bastard Programmer from Hell 
|
|
|
|
|
I have some custom controls and some forms that inherit from other forms. You might be on to something there.
|
|
|
|
|
Thanks for all the replies. I shall check my project next time I have it open and see if any of the suggested causes might be in play for my project.
|
|
|
|
|
Hello,
i have a question regarding the System::Windows::Forms::ListView. There's a bug witch i can't get rid of.
The intention was to create a ListView item whose last column adjusts to the available space of the surrounding panel. Please check the following code:
Form1.h:
#pragma once
#include "MDIChild.h"
namespace ListView_Test {
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
public ref class Form1 : public System::Windows::Forms::Form
{
public:
Form1(void)
{
InitializeComponent();
MDIChild ^ child = gcnew MDIChild();
child->MdiParent=this;
child->Show();
}
protected:
~Form1()
{
if (components)
{
delete components;
}
}
private:
System::ComponentModel::Container ^components;
void InitializeComponent(void)
{
this->SuspendLayout();
this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);
this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
this->ClientSize = System::Drawing::Size(1060, 484);
this->IsMdiContainer = true;
this->Name = L"Form1";
this->Text = L"Form1";
this->ResumeLayout(false);
}
};
}
MDIChild.h:
#pragma once
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
namespace ListView_Test {
public ref class MDIChild : public System::Windows::Forms::Form
{
public:
MDIChild(void)
{
InitializeComponent();
}
protected:
~MDIChild()
{
if (components)
{
delete components;
}
}
private: System::Windows::Forms::ListView^ listView1;
private: System::Windows::Forms::ColumnHeader^ columnHeader1;
private: System::Windows::Forms::ColumnHeader^ columnHeader2;
private: System::Windows::Forms::ColumnHeader^ columnHeader3;
private: System::Windows::Forms::ColumnHeader^ columnHeader4;
private: System::Windows::Forms::ColumnHeader^ columnHeader5;
private: System::Windows::Forms::ColumnHeader^ columnHeader6;
private: System::Windows::Forms::ColumnHeader^ columnHeader7;
private: System::Windows::Forms::ColumnHeader^ columnHeader8;
System::ComponentModel::Container ^components;
#pragma region Windows Form Designer generated code
void InitializeComponent(void)
{
System::Windows::Forms::ListViewItem^ listViewItem1 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"1",
L"a", L"b", L"c", L"d", L"e", L"f", L"g", L"h"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem2 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"2",
L"b", L"c", L"d", L"e", L"f", L"g", L"h", L"i"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem3 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"3",
L"c", L"d", L"e", L"f", L"g", L"h", L"i", L"j"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem4 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"4",
L"d", L"e", L"f", L"g", L"h", L"i", L"j", L"k"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem5 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"5",
L"e", L"f", L"g", L"h", L"i", L"j", L"k", L"l"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem6 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"6",
L"f", L"g", L"h", L"i", L"j", L"k", L"l", L"m"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem7 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"7",
L"g", L"h", L"i", L"j", L"k", L"l", L"m", L"n"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem8 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"8",
L"h", L"i", L"j", L"k", L"l", L"m", L"n", L"o"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem9 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"9",
L"i", L"j", L"k", L"l", L"m", L"n", L"o", L"p"}, -1));
System::Windows::Forms::ListViewItem^ listViewItem10 = (gcnew System::Windows::Forms::ListViewItem(gcnew cli::array< System::String^ >(9) {L"0",
L"j", L"k", L"l", L"m", L"n", L"o", L"p", L"q"}, -1));
this->listView1 = (gcnew System::Windows::Forms::ListView());
this->columnHeader1 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader2 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader3 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader4 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader5 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader6 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader7 = (gcnew System::Windows::Forms::ColumnHeader());
this->columnHeader8 = (gcnew System::Windows::Forms::ColumnHeader());
this->SuspendLayout();
this->listView1->Anchor = static_cast<System::Windows::Forms::AnchorStyles>((((System::Windows::Forms::AnchorStyles::Top | System::Windows::Forms::AnchorStyles::Bottom)
| System::Windows::Forms::AnchorStyles::Left)
| System::Windows::Forms::AnchorStyles::Right));
this->listView1->Columns->AddRange(gcnew cli::array< System::Windows::Forms::ColumnHeader^ >(8) {this->columnHeader1, this->columnHeader2,
this->columnHeader3, this->columnHeader4, this->columnHeader5, this->columnHeader6, this->columnHeader7, this->columnHeader8});
this->listView1->FullRowSelect = true;
this->listView1->HeaderStyle = System::Windows::Forms::ColumnHeaderStyle::Nonclickable;
this->listView1->Items->AddRange(gcnew cli::array< System::Windows::Forms::ListViewItem^ >(10) {listViewItem1, listViewItem2,
listViewItem3, listViewItem4, listViewItem5, listViewItem6, listViewItem7, listViewItem8, listViewItem9, listViewItem10});
this->listView1->Location = System::Drawing::Point(6, 15);
this->listView1->Name = L"listView1";
this->listView1->Size = System::Drawing::Size(710, 110);
this->listView1->TabIndex = 2;
this->listView1->UseCompatibleStateImageBehavior = false;
this->listView1->View = System::Windows::Forms::View::Details;
this->listView1->SizeChanged += gcnew System::EventHandler(this, &MDIChild::ResizeListView);
this->columnHeader1->Text = L"Main";
this->columnHeader2->Text = L"Sub1";
this->columnHeader3->Text = L"Sub2";
this->columnHeader4->Text = L"Sub3";
this->columnHeader5->Text = L"Sub4";
this->columnHeader6->Text = L"Sub5";
this->columnHeader7->Text = L"Sub6";
this->columnHeader8->Text = L"Sub7";
this->columnHeader8->Width = 55;
this->AutoScaleDimensions = System::Drawing::SizeF(6, 13);
this->AutoScaleMode = System::Windows::Forms::AutoScaleMode::Font;
this->ClientSize = System::Drawing::Size(721, 139);
this->Controls->Add(this->listView1);
this->Name = L"MDIChild";
this->Text = L"MDIChild";
this->ResumeLayout(false);
}
#pragma endregion
void ResizeListView(System::Object ^ sender, System::EventArgs ^ e)
{
try
{
ListView ^ list = listView1;
int nSize = 3;
int nLastIndex = 7;
int nLastColumnSize;
nSize += list->Columns[0]->Width;
nSize += list->Columns[1]->Width;
nSize += list->Columns[2]->Width;
nSize += list->Columns[3]->Width;
nSize += list->Columns[4]->Width;
nSize += list->Columns[5]->Width;
nSize += list->Columns[6]->Width;
nLastColumnSize = 200;
nSize = list->ClientRectangle.Width - nSize - 19;
if (nSize > nLastColumnSize)
{
nLastColumnSize = nSize;
}
list->Columns[nLastIndex]->Width = nLastColumnSize;
}
catch(...)
{
;
}
}
};
}
As you can see an outer panel(Form1) serves as an MDI container for the interior(MDIChild) which contains the list view.
But if a list view item is displayed, witch content encompasses so many lines that the vertical scroll bar appears, a interessting repaint error arises when maximizing. But only if the ListView was scrolled down bevor the maximize. Presumably it happens because i set the size of the last column header, while the list view is redrawn.
Reproduction:
1.Execute the code posted above.
2.Move the vertical scroll bar of the "MDIChild" window to the bottom.
3.(optional) maximize the Form1.
4.The MDIChild maximize window.
Symptoms:
First, no line is displayed. If we try to mark some lines with a marking-rectangle, it is noticeable that they will not appear until you move the mouse over them. But at the wrong place. They seem to be moved downwards exactly of the height of the non-maximized panel. Even after you press the minimize button, the rows remain initially disappeared, until you move the scroll bar to the bottom.
Additionally a horizontal scroll bar is present, which is, compared to the size of the list view, much to wide. When you move it to the right side, the scroll bar is reduced to the proper width.
Can anyone help me with this problem? -In appendix there is a screenshot showing the problem.
Sincerely,
Michael
|
|
|
|
|
Have you tried handling the Layout event, instead of Resize?
On the resize page, it is suggested that for a custom layout (of child elements), that Layout should be handled instead of resize. I'm guessing it might affect the repaint and re-positioning of the child controls, hopefully removing the bug.
Control.Resize Event[^]
Control.Layout event[^]
|
|
|
|
|
Hi experts,
the problem described in an earlier message[^] has changed sightly.
An application I'm developing needs to tell user that it is busy while doing some long-term processing and communication with hardware devices in a separate thread. User, in the meantime, needs to press some buttons on those hardware devices depending on what the application shows on screen. But the application itself shall be locked from user interaction with the exception of a "Cancel" button.
I therefore made most controls (excluding the "Cancel" button)
control.UseWaitCursor = true;
control.Enabled = false;
When busy time ends, controls are set back to
control.Enabled = true;
control.UseWaitCursor = false;
A problem I had was that WaitCursor was also shown on the "Cancel" button. That was because I had set the whole Form to UseWaitCursor = true after processing all individual controls. Having removed this erronuous command now, WaitCursor doesn't show up at all.
By playing around a little, I found out that UseWaitCursor = true has no effect on controls that are set to Enabled = false irrespective of command order.
Are there any suggestions for
1. Disabling all controls except for "Cancel" button
2. Showing WaitCursor on all controls except for "Cancel" button
Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.
Ciao,
luker
|
|
|
|
|
Can you get all the controls except the Cancel button onto a Panel? If so, disable the Panel.
If not, use the Tag property on the Cancel button, say "AlwaysOn". Then loop through all the controls on the form and disable any that don't have a Tag property of "AlwaysOn".
|
|
|
|
|
Thank you, that is nearly what I already implemented to determine which controls to disable and which to leave responsive.
My problem is this: a control has UseWaitCursor set to true. It shows the WaitCursor, but user can still use it (click button, slide slider, whatever).
The same control has Enabled set to false. Now it is inaccessible, as intended, but doesn't show UseCursor any more. Instead the normal arrow cursor is shown, which is not intended.
How can I disable a control and show WaitCursor at the same time?
Ciao,
luker
|
|
|
|
|
I suppose you could intercept the OnClick and do nothing if the wait cursor is still applied, or similar status checking.
|
|
|
|
|
lukeer wrote: Are there any suggestions for
1. Disabling all controls except for "Cancel" button
2. Showing WaitCursor on all controls except for "Cancel" button
Luc Pattyn already suggested[^] a modal dialog which is impossible due to the information on screen that user needs to press the correct buttons as mentioned above.
Think about it this way: you are still using and displaying information to the user on the form. Thus, the form is not currently busy, thus it shouldn't show a Wait cursor. The wait cursor is meant for if your form is busy and unable to interact for a while. This is not the case here.
Disabling all unavailable controls is already a very good hint that the form is 'working' on something, but it also shows that the form is still valid and ready for use. If you set the wait cursor on your form (even if it's not on your cancel button) then I'd get confused as a user: the wait cursor tells me that the form is currently unresponsive, pending the completion of an operation. But it isn't.
My advise to you: don't use the Wait cursor for this. It's confusing.
|
|
|
|
|
My vote goes to MicroVirus' analysis here: you need to think about your design in the context of what people are socialized to in using Win Applications.
However, there are still things we don't know about the context of what you are doing that are quite important: you mention there's more than one "hardware" something that the app interacts with, and you imply that while the app may still be busy with some other hardware something(s), that one (more than one ?) other hardware something may have some controls presented in the app the user can interact with.
We don't know if there's an implicit sequence here ... access to hardware something #1 completes ... and then you interact with its controls while hardware something #2 is accessed ... and so on. Or, whether this whole thing is asynchronous, with hardware something #n going out for lunch whenever.
I suggest you think about a progress bar, or multiple progress bars here.
But "design" also depends on what you want your user to know in the context of your unique application: your specific application, perhaps, doesn't need to let the user know that the app is busy accessing hardware something(s) #1 ... #n ?
best, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
|
|
|
|
|
Thanks, Bill. I not only need to think about the design, but also about how to convince my customer that the reconsidred design is what he wants. For now, he wants the controls disabled and with WaitCursor.
For the important things we don't know yet:
There are several "hardware" somethings (devices). Let's call them Charlie, Augustus, Veruca, Violet and Mike.
The application shows several controls. One of them is some kind of "announcer" control. There is no 1-on-1 coupling between controls and devices.
User can start a sequence in which announcer says "Go to Chalie. Press the red button."
User then goes to "hardware" something called Chalie and presses the red button.
Announcer changes to "Go to Augustus. Press the red button."
User goes to Augustus and presses the red button.
Announcer changes to "Go to Veruca. Press the red button."
And so on until Mike's red button has been pressed.
While user is on his way pressing hardware buttons, there is no need for him to touch any of the application's controls (with the exception of "Cancel" button). Therefore controls shall be disabled and show the WaitCursor.
Since some controls (e.g. ListView) don't gray-out text when disabled, the additional WaitCursor would be a really great benefit. But it seems that disabling a control also disables its ability to show WaitCursor.
How can I disable a control and make it show WaitCursor at the same time?
Ciao,
luker
|
|
|
|
|
Kind of thinking "out of the box:" have you considered using a small animated gif file in a PictureBox to serve the same purpose as the WaitCursor ?
Check out: [^]
Just a thought, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
|
|
|
|
|
lukeer wrote: How can I disable a control and make it show WaitCursor at the same time?
Simple answer: you can't. I've experimented with this a little, just like you have.
What you are seeing here is base Windows functionality. If a parent uses the Wait Cursor, then all children are considered to be 'waiting' as well. A disabled control has no user interaction, so using a Wait Cursor on that doesn't work.
I've become quite convinced that there is no out-of-the-box way to achieve this. I'm guessing it's probably possible, but you're going to have to dig deep into the window procedure for the form and possibly for the child control as well. For a measly thing such as a cursor change, it's not worth the trouble and issues.
However, Bill has suggested an alternative, which I must admit sounds much better. I still think the Wait cursor idea is too much against common practice with what users are used to  .
So, I suggest going with an alternative.
|
|
|
|
|
Was there a final resolution to this issue of having a disabled control AND a wait cursor at the same time?
Cheers,
Mike Fidler
|
|
|
|
|
Sadly enough, no.
I stayed with WaitCursor and enabled controls. In case of some user clicking anything, the software shows an error message.
Ciao,
luker
|
|
|
|
|
Goal: Have the WaitCursor over a disbled control
I experimented a little bit on a small C# form app.
Add a Panel to the form and make it the size of the Button you want to add.
Add the Button to the Panel and set Dock = Fill
(Panel obviously becomes the parent of the Button)
Disable the Button (Enabled = false)
Set Panel's UseWaitCursor = true
When the the app runs, the button will be disabled and
the WaitCursor will be visible over it.
Conclusion:
Use a parent panel to control WaitCursor visibility over a disabled control.
It's extra work but you can have what your customer wanted.
Cheers,
Mike Fidler
|
|
|
|
|
The question: given the variety of visual effects in Vista and Win7 possibly applied to Windows Forms in .NET, depending on system settings, themes, etc., can you algorithmically determine the precise boundaries of the display area of a Form where 'display area' is defined as exclusive of window borders, titlebar height, side-effects of visual settings like 'shadows' on Forms, etc.
And, oh yes, I don't wanna get near importing and using any API stuff ! 
Context: WinForm application, Visual Studio 2010 Pro, Win 7 Pro with all updates, 4 gigs of ram, older duo-core Intel CPU. GeForce 7100GS video card. Screen resolution: 1280x768
A concrete example:
only W7 visual effects enabled:
1. desktop composition
2. use visual styles on buttons and windows
In this software/hardware context: creating a "main" WinForm with a size set, in the design-time form editor, to, for example, 816,638, gets you this in the Designer.cs file:
this.ClientSize = new System.Drawing.Size(800, 600); Now, I add a second Form at run-time to my WinForm app, and I set its owner to be the "main form."
So: I write a re-size event-handler for this added, second, Form, so that I essentially keep it in the client display rectangle of the main Form: here's the way I (now) calculate the revised owner's client rectangle for "out of bounds detection:"
private Rectangle ownerClientRectangle;
private Rectangle currentClientRectangle;
private Rectangle intersectRectangle;
ownerClientRectangle = RectangleToScreen(RectangleToClient(this.Owner.Bounds));
ownerClientRectangle.Inflate(-14, -24);
ownerClientRectangle.Offset(0, 12);
currentClientRectangle = this.Bounds;
intersectRectangle = currentClientRectangle;
intersectRectangle.Intersect(ownerClientRectangle);
At this point I can be sure ... in this context only ... that if :
intersectRectangle != currentClientRectangle
Then the second Form is outside the boundaries of its owner ("main") Form, and I can 'do the right thing' to re-position it, which is simple.
The problem here is those magic numbers I am using for shrinking (negatively inflating), and off-setting the owner form's Bounds.
Of course I want to derive those inflation factors and offsets by calculation, not 'fiddlin around'
If those W7 graphic effects are turned off: the main Form that in the Designer.cs file is still written out as size 800,600: now appears, in the design-time property editor, with a size of : 808, 627 ... and, of course, the code for keeping the second Form in the boundaries of the first Form no longer works properly.
Appreciate any thoughts or advice !
thanks, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
modified on Sunday, September 4, 2011 10:08 PM
|
|
|
|
|
I have had similar problems, the thing (from what I have gathered) is that when you set the ClientSize property the form resizes then changes the ClientSize again based on the theme settings (i.e. title bar header sizes).
The outcome being your form keeps growing/shrinking (once) every time you show/hide.
The best workaround I have found is to set the form size instead.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
Thanks for your response, Mehdi,
In this case, I am using the "shrunken" bounding box of the client area of the Owner Form to hit test when a second, "owned" (but not child) Form is moved, and re-positioning the second Form to always remain in the boundaries of the first form.
When I have time, I am going to experiment further with the differences between Form.Bounds, and the other Form-level 'area' properties under different conditions of configuring Win 7 visual effects, and see if I can't come up with some kind of compromise.
best, Bill
"Is it a fact - or have I dreamt it - that, by means of electricity, the world of matter has become a great nerve, vibrating thousands of miles in a breathless point of time? Rather, the round globe is a vast head, a brain, instinct with intelligence!" - Nathanial Hawthorne, House of the Seven Gables
|
|
|
|
|
Cheers Bill,
I will try and investigate more (I gave up that feature last time!), let you know.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
