|
I have a grid control with a number of properties, including colCount, rowCount and rowFooterFillType.
When I change them in designer, they get written into <class>.designer.cs in alphabetic order.
The initialization happens in this order:
newGrid.colCount = 8;<br />
newGrid.rowCount = 4;<br />
newGrid.rowFooterFillType = Type.typeOf("System.Windows.Forms.Label");
What happens is that the grid is created, it is sized, and then it finds out that each of the columns was supposed to create a footer of type "Label".
It makes more sense for the code to be initialized like so:
newGrid.rowFooterFillType = Type.typeOf("System.Windows.Forms.Label");<br />
newGrid.colCount = 8;<br />
newGrid.rowCount = 4;
That way, when the rows are created, they already know what type of footer to use, and create them like I want.
I can go in and change the order of the code designer put out, but that does no good the next time I change one of the attributes in designer, since designer puts them back into alpha order.
Anyone got any good ideas?
Thanks
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
I suggest you don't attempt to control the order the properties are called in. In fact, this is a violation of the FxCop (.NET rules) specification - properties are supposed to be black box so that it doesn't MATTER what order you set them in.
That said, it is obviously unrealistic to expect properties to not affect each other. This is why the designer supports the BeginInit() and EndInit() methods from the ISupportInitialize interface. The designer will automatically insert BeginInit() before it sets any of your properties, and will call EndInit() when they're done.
What you can do with this is when BeginInit is set, set a flag in your code to true, and as long as it is true, simply update your backing field for the properties. Don't do any processing on them.
When EndInit() is called, unset your flag, and execute all of the code that should be executed to make all of your properties take effect.
All you need to do to support this behavior is add " : ISupportInitialize" to your class declaration and implement the appropriate methods.
Read more about it here[^]
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
|
|
|
|
|
THANK YOU!
I know it is not the best behavior, but I am setting default types for the grid cells, and I sort of need to know what they are BEFORE I create the cells, since the user might change the default for new cells, without wanting to re-initialize the old cells.
ISupportInitialize looks like it will be just the trick.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
RichardM1 wrote: I know it is not the best behavior, but I am setting default types for the grid cells, and I sort of need to know what they are BEFORE I create the cells, since the user might change the default for new cells, without wanting to re-initialize the old cells.
Nah, it sounds fine. Sometimes this is the simplest approach, even if it seems like it's not elegant enough. I've learned that if it takes 32 hours to come up with an elegant solution, when a less-elegant-but-equally-workable-solution will do, implementing the elegant solution is a waste of time.
ISupportInitialize is pretty cool  I don't use it often, but when I do need it I'm damn glad it's there..
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
|
|
|
|
|
LOL!
It is like a hammer:
Sometimes a jeweler's screw driver just will not make the TV work, so you have to use the hammer.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
I need help with following problem:
I created new project with two Windows Forms called Form1 and Form2. Now, I put on each Form one Button and one Text Box.
The main Form is Form1 which I start the program. When I click Button1, Form2 shows and into Textbox1 in Form2 it puts some text. To do this in Form1 I added code:
#include "Form2.h"
...
private: Form2^ form2;
...
private: System::Void button1_Click(System::Object^ sender, System::EventArgs^ e)
{
form2 = gcnew Form2();
form2->textBox1->Text="sometext";
form2->Show();
}
Everything works fine, but..... Now I want do the same in opposite direction. I want to click on Button1 on Form2 and put some text into textbox1 on Form1. How to do this????
I cannot add in Form2 #include "Form1.h" because it will not compile(There are some errors)
Please help me with this "simple" problem.
Best regards
Szymon
|
|
|
|
|
First, you really need to break the habit of a Form directly modifying another Form. Comming from a C++ world, you should already know about OOP and encapsulation. What you're doing is breaking the rules of encapsulation for sure because a Form (class actually) needs to know about the internals of another class. You're explicitly tying those two classes together to the point where one cannot exist without the other. Does that sound like good encapsulation to you??
Get into the habit of creating a data model first, completely independent of a user interface. I know it's a bit overkill for such a simple example as what you're doing now, but the experience comes in very handy when your projects become larger and larger, and when you need to run the same app as both a Windows Forms app and as a Web Forms app.
For your case, a class that exposes a property that hold the "message" being passed between forms would work just fine. This property would fire an event that either (or both) forms can subscribe to so that if either form, at any time, set the property (call it "Message"), both forms (or even more) would get notified of the change and be able to update their own UI components themselves. Neither form has to know anything about the other.
|
|
|
|
|
Thanks, Could you put here example of code, which I can use? How would my code looks then to obtain task I want?
Szymon
|
|
|
|
|
A technique is to have an object that holds the data to be transfered.
For instance, a class "person", with "name", "birth date", and other fields.
For certain of the properties of person, like "birth date", you want change events.
Form 1 creates a person, and registers with the person's change events.
Form 1 then creates form 2 and passes it the person.
Form 2 knows what it wants to know about the person, and uses it, and may register itself with some of person's change events.
If form 2 has a button "Age Person" that makes person's birthday a year earlier, that will fire the change (in person), which will notify form1 that it needs to update.
Form 2 knows nothing of form 1.
Form 1 knows nothing of form 2.
Both only know what they need to about Person, and nobody knows anyones else's internals.
Person doesn't know about either of them
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
OK, I understand. So I don't need to include "Form.h" to have access to Controls of Another Form?
So if Form1 has Form1.h and Form2 has Form2.h and I declare a class let say "person" inside Form1.h. Then I create Form2 and in Form2 I change properties of person, I must declare somewhere in Form2.h that "person" class exist. In other case how Form2 will notify Form1 that properties of "person" were changed. How do I declare 'existence' of "person" in Form2??? Are you able to put some code?
Thank you
Szymon
|
|
|
|
|
You have a seperate "person.h" that defines the class "person".
Both form1 and form2 include person.h.
Form1 also includes form2.h, since it will have to create one, but it never needs to know more than the constructor.
Form2 updates itself from person, and from change events from person. Form1 does the same. So again, they have no knowledge of the internals of the other.
Bear with me on this, I have not done c++ in a while, and not without an IDE in an even longer time, so this is more psuedo code than code, or maybe it is a hybrid with c#.
person.h
class person<br />
{<br />
public person(string name, DateTime birthday);
void SetName(string name);<br />
string GetName();<br />
void SetBDay(DateTime birthday);<br />
string GetBDay();<br />
void AddBDayChangeCallBack(callBackType callBack);<br />
void DelBDayChangeCallBack(callBackType callBack);<br />
}
person.cpp
class person<br />
{<br />
private string m_name = "";<br />
private DateTime m_birthDay = new DateTime();<br />
private callBackTypeList m_bDayChangeCallbacks = new callBackTypeList();<br />
<br />
public constructor person(string name, DateTime birthday)<br />
{<br />
SetName(name);<br />
SetBDay(birthday);<br />
}<br />
void SetName(string name){}<br />
string GetName(){}<br />
void SetBDay(DateTime birthday)<br />
{<br />
m_birthDay = birthday;<br />
foreach(callBackType event in m_bDayChangeCallbacks)<br />
{<br />
invoke(event(this)); <br />
}<br />
}<br />
string GetBDay(){}<br />
void AddBDayChangeCallBack(callBackType callBack)<br />
{<br />
bDayChangeCallbacks.Add(callBack);<br />
}<br />
void DelBDayChangeCallBack(callBackType callBack)<br />
{<br />
bDayChangeCallbacks.Remove(callBack);<br />
}<br />
}
So form1 and form2 both include person.h.
form1.h and form2.h do not expose any of the components of the forms, just constructors/destructors.
The form2 constructor takes a person as a parameter, and that is how it is notified of the person, though you could also have a "void SetPerson(person perp);" definition somewhere.
Wow. That is too bad they flatten indentation.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
Person exists in its own right, it has no relationship to any form, hence its class
is not inside Form1, it is in a separate file, say Person.h
Form1 and Form2 are ways to interact with Person, they are separate classes in separate
files.
Doing so, both Form1 and Form2 need to know about Person, but not about each other.
|
|
|
|
|
MUCH more condensed and readable than what I said.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
That is because Luc is the MAN. (congrats on the MVP by the way, Luc!)
It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein
|
|
|
|
|
Thanks. I try and help where I can.
|
|
|
|
|
And no code at all, since I don't speak C++ fluently... 
|
|
|
|
|
(shaking head)
If you look at what I wrote, it's probably obvious I don't, as well.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
RichardM1 wrote: it's probably obvious I don't, as well
I truely can't tell, at least until I pass it to the compiler.
I did not really study your post, we both were replying concurrently.
BTW: you can (and should) preserve formatting by using PRE tags
(CODE tags are good for single-line captions, PRE is useful for multi-line).
|
|
|
|
|
Thank you Sir, you are a scholar and a gentleman.
I want to die like my Grandfather.
Peaceful, Sleeping.
Not screaming like his passengers.
|
|
|
|
|
Had to look that up, the saying was unknown to me. Thank you kindly.
|
|
|
|
|
I dont' have any C++ code. I haven't touched it so long.
|
|
|
|
|
I have C# app whose main window can be hidden (there's a NotifyIcon tray icon to allow it to be shown). In the FormClosing() function I check whether a shutdown is in progress and don't cancel that event if it is. If the PC is not shutting down the form is simply hidden.
Here's the problem: When I logoff/shutdown the PC, the mainforms FormClosing() function does not get called if it is hidden (i.e. in the tray) and thus the app never ends.
If the main form is visible it exits just fine.
I've looked high and low, but am unable to figure out what to trap in order to exit gracefully when the user logs off.
Any ideas/pointers?
Thanks,
- Lutz
|
|
|
|
|
Hi,
have a look at SystemEvents.SessionEnding and SystemEvents.SessionEnded events then.
|
|
|
|
|
|
Actually, it turns out this one was dev error. 
So when my form was minimized/hidden to tray, it did in fact get the Form_Closing event. But that method was checking System.Environment.HasShutdownStart() which returned false, even when I was in fact trying to logoff/shutdown.
However, it turns out that the FormClosingEventArgs for the closing handler tells you in the CloseReason why it's wanting to close, so once I removed that call and changed it to see whether e.CloseReasons was CloseReason.WindowsShutDown it worked fine.
The SystemEvent handlers you mentioned only get called once FormClosing allows the form to close. It wasn't getting called before I made the above fix.
Thanks for making me actually sit down and write a test app to see how this works 
- Lutz
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
