|
Yes, it is. An MDI Child form can launch an instance of another form, so long as the MDI Child does not try and become an MDI Parent to that new form.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Is it even legal to have a parent-child relationship anymore?
|
|
|
|
|
What's the best way of storing an application setting to read it later? Do I have to resort to a text file or is there some better way with .NET 2.0?
|
|
|
|
|
I would store them in the app.config file.
// Get the application configuration file.
System.Configuration.Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);
///Make changes to the config file. Perhaps in someplace like appSettings
//then save
config.Save();
Hope that helps.
Ben
|
|
|
|
|
Depends on your needs. If it's simple data, use an App.config or the Web.config if you're doing a web app. You can just add keys to them which are easy enough to retrieve.
<configuration>
<appSettings>
<add key="field" value="1" />
</appSettings>
...
</configuration>
Then in code you can access them with something like...
string field = System.Configuration.ConfigurationSettings.AppSettings("field");
But if you have more complex data that you need to store, I usually do my own XML structure and use something like Skeleton Crew[^] to build a code model to use it with.
|
|
|
|
|
Which is better?
1. Set a member of a class as public
<br />
public class SearchBox<br />
{<br />
public string keyWordString;<br />
<br />
public SearchBox()<br />
{<br />
}<br />
}<br />
-or-
2. Set a member of a class as private and create a public property for that member.
<br />
public class SearchBox<br />
{<br />
private string keyWordString;<br />
<br />
public string KeyWord<br />
{<br />
get<br />
{<br />
return this.keyWordString;<br />
}<br />
<br />
set<br />
{<br />
this.keyWordString = value;<br />
}<br />
}<br />
<br />
public SearchBox()<br />
{<br />
}<br />
}<br />
Both options do the same action. What are the advantages/disadvantages of one over the other?
Thanks
Rob Tallent
|
|
|
|
|
Always use Public properties. It is good OO design along with allowing you to only give out what is needed. It is easy to change the public property to readonly by removing the set method. You can't really do that with the Public Var. Also the public method allows you to do some extra coding if needed. Perhaps in the Get method you have some stuff like:
if (this.keywordstring == null)
{
//get default from where ever...
}
Anyway that is my two cents.
Ben
|
|
|
|
|
Encapsulating your data members by hiding them and exposing a property lets you control access to the member. Just a public field allows somebody to put any value in the variable, which may or may not be a valid value for the class.
All your classes should have well defined expected input. It should be able to guaranty a valid result given expected input, so you have to be able to control that input and notify when the input is invalid.
Does that help?
|
|
|
|
|
|
Properties have many uses: they can validate data before allowing a change; they can transparently expose data on a class where that data is actually retrieved from some other source, such as a database; they can take an action when data is changed, such as raising an event, or changing the value of other fields; they can be read-only.
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." - Rick Cook www.troschuetz.de
|
|
|
|
|
<sniff> <sniff> I smell homework. True?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Nah, I paid him off to bring up a subject I tried, without success, to discuss in the lounge a while ago.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
There is almost no difference, so long as your class is never going to be in a dll, or otherwise reflected on. Either way, it does the same thing. It's true that much religious discussion occurs over public properties, but what is often missed is that the *point* of using public properties is that you can change the visibility of the set method and leave the get as public. If you just use properties instead of variables, but don't think about what visibility you use, then you've really missed the point.
Use properties, only because it's cleaner to always do so. But, remember also to always think about showing as much as you need to, and no more. I make all setters private to start with unless it's totally clear they need to be exposed, and change them if I need to.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
"I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
|
|
|
|
|
I forgot that with 2.0 you can specify seperate visiblity modifiers. That was something I'd always wanted, and forgot about once it was there.
|
|
|
|
|
Can't resist.
As every OOP reference you can digest addresses this issue, we should just point you to the best of them -- Stroustrup, Meyers, Richter. These clearly establish the proper implementation of properties, which is central to OOP. If you are not willing to do your homework, you will be stuck in a rut for just however long you continue to do so.
Still, you don't learn *everything* from books -- and many good books might be a bit timid about venturing concepts which, if excercised carelessly, would lead you to folly.
I might be considered "daring" (not to be confused with unsafe or dangerous), because I'm adamant about the conceptually hidden side of properties -- the fields we use to store their values to. Most programmers routinely make their fields private. But they are hidden from all things outside the class, even if they are protected internal. Furthermore, exercising protected internal will often allow you to do things much faster than you can otherwise, because internal processes acting on the field do not have to pass through an accessor. There are many iterative processes which can be made much faster by taking advantage of this elevated field *exposure*.
So, I do this quite often (whenever appropriate, and always when appropriate), and it has never been a critical issue.
The real point however is that *whatever* you do in the way of exposure of *anything* is *all* a matter of the ramifications of the exposure. To "know" what you are doing with exposure is to cover every ramification.
Always.
|
|
|
|
|
Another thing that wasn't mentioned is that properties are integral with serialization, and with design time processes which allow us to interact with objects in the visual development environment. These purposes too establish when and how to use properties (together with attributes).
|
|
|
|
|
Hi all,
I read data from a database, fill a datagrid with them and create an XML-File via datagrid.RenderControl()
So I get an XML-file with extension xls, which Excel can read.
But with some field values Excel gets lost.<br />
<br />
Example of such a file (save as test.xls):<br />
<table cellspacing="0" rules="all" border="1" id style="border-collapse:collapse;"><br />
<tr><br />
<td>Text</td><td>Date</td><td>Value1</td><td>Value2</td><br />
</tr><br />
<tr><br />
<td>First</td><td>2006-01-26</td><td>0</td><td>0</td><br />
</tr><br />
<tr><br />
<td>+Second</td><td>2006-01-26</td><td>0</td><td>0</td><br />
</tr><br />
<tr><br />
<td>Third</td><td>2006-01-26</td><td>0</td><td>0</td><br />
</tr><br />
</table>
The first line shows okay in Excel, but after the '+'-Sign in the second line all date- and numberfields are shown as text fields. Now for calculations all first have to be converted.
Does anyone know how to avoid this problem?
Thank you!
Martin
2B||!2B?
|
|
|
|
|
Windows controls have BringToFront() and SendToBack() methods, but is there a property that gives you access to the Z index? Or do I need to keep track of it myself? Reason I ask, I want to save the state of movable controls so I can restore that state. Anybody dealt with this?
|
|
|
|
|
I see, BringToFront and SendToBack change the index of the Controls collection. Their order in the collection is their Z order.
|
|
|
|
|
Each control should have a TabIndex on it. Each control should also have a TabStop property. This should control what the tab order is on your windows form.
By the way, to initially set this tab order there is a cool thing you can do in Visual studio. Open up your form. Then go to View Tab Order. This will show numbers next to all the controls on your form. At that point you can start to click on controls and re-set the tab order to a different order. Hit the esc key when done. Anyway, I think that is a cool feature.
Hope that helps.
Ben
|
|
|
|
|
What I have is a few picture boxes that you can drag around the form. When you click on one, it's brought to the front. So I need to keep track of what is supposed to be on top of what. I'm not sure that tab index would give me the correct data for this situation.
But thanks for the suggestion. I had seen the View Tab Order dialog before, but forgot it was there. Definitely good to know.
|
|
|
|
|
I'm a noob to C#, so bear with me.
I have the following class and form:
<br />
using System;<br />
using System.Collections.Generic;<br />
using System.ComponentModel;<br />
using System.Data;<br />
using System.Data.SqlClient;<br />
using System.Drawing;<br />
using System.Text;<br />
using System.Windows.Forms;<br />
<br />
namespace tracker<br />
{<br />
public partial class frmMain : Form<br />
{<br />
SqlConnection objDBConnection;<br />
SqlDataAdapter objDBAdapter;<br />
DataSet objDBDataSet;<br />
DataGridView objDBGridView;<br />
<br />
public frmMain()<br />
{<br />
InitializeComponent();<br />
}<br />
<br />
private void frmMain_Load(object sender, EventArgs e)<br />
{<br />
this.objDBConnection = new SqlConnection("Server=BigHouse;Database=tracker;Trusted_Connection=yes");<br />
try<br />
{<br />
this.objDBConnection.Open();<br />
this.toolStripStatusLabel1.Text = "Connected to Tracker database";<br />
}<br />
catch (Exception connerr)<br />
{<br />
this.toolStripStatusLabel1.Text = "Cannot connect to Tracker database";<br />
}<br />
<br />
<br />
this.getProjectGridData();<br />
<br />
<br />
DataRow r = this.objDBDataSet.Tables["tbl_projects_main"].Rows[0];<br />
Console.WriteLine("num records = " + <br />
this.objDBDataSet.Tables["tbl_projects_main"].Rows.Count + <br />
" and " + <br />
r["prj_name"].ToString());<br />
<br />
<br />
this.objDBGridView = new DataGridView();<br />
this.objDBGridView.DataSource = this.objDBDataSet.Tables["tbl_projects_main"];<br />
this.objDBGridView.AutoGenerateColumns = true;<br />
this.objDBGridView.Location = new Point(0, 0);<br />
this.objDBGridView.Size = new Size(700, 490);<br />
this.objDBGridView.MinimumSize = new Size(700, 490);<br />
this.objDBGridView.BackgroundColor = System.Drawing.Color.AliceBlue;<br />
this.objDBGridView.AutoResizeColumns(DataGridViewAutoSizeColumnsMode.AllCellsExceptHeader);<br />
<br />
this.objDBGridView.Visible = true;<br />
}<br />
<br />
private void getProjectGridData()<br />
{<br />
string strSql;<br />
strSql = "SELECT * FROM dbo.tbl_projects_main";<br />
this.objDBDataSet = new DataSet();<br />
this.objDBAdapter = new SqlDataAdapter();<br />
this.objDBAdapter.SelectCommand = new SqlCommand(strSql, this.objDBConnection);<br />
this.objDBAdapter.Fill(this.objDBDataSet, "tbl_projects_main");<br />
}<br />
}<br />
}<br />
I know I'm getting records and info back from the database, but nothing shows up on my form - no datagridview to be seen anywhere.
Any help is appreciated.
|
|
|
|
|
I am pretty sure you need a databind after you set the datasource.
Ben
|
|
|
|
|
As far as I can see, you do all the data stuff fine, but you never actually add the datagridview to the form itself. Try this.Controls.Add(objDBGridView);
|
|
|
|
|
Thanks to both of you. The real kicker was this.Controls.Add(objDBGridView). I had looked at that before and thought, "Nah. Couldn't be."
Well, I was wrong. 
Thanks!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
