|
Dave Kreskowiak wrote: So how is passing off someone elses work as your own going to help?
i believe we are all here to help each other and if i got this work from some one else i will not say it is mine... that is not my manners
Dave Kreskowiak wrote: What are you going to do when the code breaks and you have no idea how it works?
i know this code is not a big deal... and i know it is understandable by any one.
|
|
|
|
|
marwan_siala wrote: i believe we are all here to help each other and if i got this work from some one else i will not say it is mine... that is not my manners
We're here to help you write your own code. Not just hand over something prewritten for you.
marwan_siala wrote: and i know it is understandable by any one.
Wanna bet?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
It's not a big deal AND it's understood by anyone, yet he can't write it ? 
I am convinced that there is a subset of CPians that represents people who take RentaCoder jobs then post questions here to get them done. I'm also convinced that you and I will have jobs for a long time, judging by how many people post homework here, verbatim.
You're not summitting, are you ? I leave next Friday.
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 )
|
|
|
|
|
Christian Graus wrote: It's not a big deal AND it's understood by anyone, yet he can't write it ?
My point exactly! 
Christian Graus wrote: I am convinced that there is a subset of CPians that represents people who take RentaCoder jobs then post questions here to get them done.
You know, I haven't thought of that, but your absolutely right. I'd be willing to bet that's exactly what's going on! 
Christian Graus wrote: You're not summitting, are you ? I leave next Friday.
No, I'm not  I'm still working 60-80 a week pulling my hair out over what other people are building and calling "Production Quality".  Sadly, it's my yob to support the crap they put out and call "tested".
I have sweatshirt I'm seriouly thinking of wearing to work. Acrossed the front it say "Is it me, or is this place a festival of idiots?";)
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
ok i have gain time extension... and i am stuck here...
as i said i am using c# .net 2005
i need to convert Byte[] to network stream .. how is that
thanks
or better convert Byte[] to image ( using System.Drawing )
-- modified at 11:52 Monday 26th February, 2007
|
|
|
|
|
Hi All,
I am using datlist on the basket page, in the i have a text box for quantity.
as you all know that there will be multiple lines in the basket i just get the dataset and bind that to Datalist.
I have to validate the textbox quantity to accept only the numberic chars. I was trying to capture the kedown event which i cannot use as the textbox is bound on datalist.
Can any one give me some suggestions of advice how to hadle this.
|
|
|
|
|
Hi all
iwant to know that cn an application have two or three parent forms??
i have a MainForm which is my current parent form. i have form1, form2, form3, form4 which are child to the MainForm.
now i want my form2 to be child to form1 and form1 to be child of MainForm.
how can i do this? if this is just not possible then plz tell me whether my application can have two parent forms like this:
MainForm ---> form1, form2
Form3 ----> form4
|
|
|
|
|
It's not really clear what you're talking about so...
There can only be one top level startup form. This form holds your application's message pump. If this form gets closed, your entire application closes with it.
Now, the rest depends on what you mean by Child forms. If you simply launching a child form by creating a new form object and showing it with .Show() or .ShowDialog(), then you can have multiple levels of children, like this:
Startup Form
|
+--->Main Form
| |
| +--->Child Form
| |
| +--->Child Form
| |
| +--->Child Form
|
+--->2nd Main Form
|
+--->Child Form
|
+--->Child Form
If you're talking about MDI Child forms, you can have multiple parent forms, each with it's own set of MDI Children. But, under Windows, it's impossible to have an MDI Child be a MDI Parent to another MDI Child form. In other words, a form cannot be both and MDI Child AND MDI Parent at the same time. You can do this:
Startup Form
|
+--->MDI Parent Form
| |
| +--->MDI Child Form
| |
| +--->MDI Child Form
|
+--->2nd MDI Parent Form
|
+--->MDI Child Form
|
+--->MDI Child Form
You CAN NOT do this:
Startup Form
|
+--->MDI Parent Form
|
+--->MDI Child Form
|
+--->MDI Child Form
|
+--->MDI Child Form
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
hi plz tell me if this is possible
Startup Form <br />
|<br />
+--->MDI Parent Form -->MDI Child Form-->Child Form
now what i wanted to know was that can the Child Form be an MdiChild of the MDI Parent Form and the Child Form at the same time?
|
|
|
|
|
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).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
