|
hi,
After I do this:
ds.Tables["tbl"].find(key) (However the talbe is not sorted by "key" column)
and I get a DataRow,
How can I get the index of that row in table rows collection? (I know a sorted DataView find method can do this but here is not what I want, also, if I sort the "key" column, my original sort order will be lost). Any ideas?
(the table primary key column is "key", and sorted by column "userName". the nearst approach I can think of is I get the userName value by the "key" value, then I create a DataView with same sort order of the table, and I find that DataView with the userName value.)
Thanks!
|
|
|
|
|
Hello,
A few days ago posted a question about how to "tie" a button event to draw a line onto a WinForm. One of the line coordinates will come from the value in a NumericUpDown control.
I was given an answer on how to do this, and it was a very good answer in that I should do all my drawing in the paint event handler and so on. But where I'm stuck is
in getting the line to draw only when the Button is clicked. I know I need some sort of
bool flag to draw the line when the button is clicked.
So to diagram ->
//Fragment 1.
private void Form1_Paint(object sender, System.Windows.Forms.PaintEventArgs e)
{
Graphics g = e.Graphics;
DrawMyLine(g);
}
//Fragment 2.
public void DrawMyLine(Graphics g)
{
g.DrawLine(somePen, 0, 0, 100, this.numericUpDown1.Value);
}
//Fragment 3. Want to draw line only if Button is clicked...
private void DrawA_Click(object sender, System.EventArgs e)
{
//??
}
//Fragment 4. How to fit in the bool flag?
Many thanks in advance......
|
|
|
|
|
Would something like this work?
private bool goAheadAndDrawTheLine;
private void Form1_Paint( object sender, System.Windows.Forms.PaintEventArgs e )
{
Graphics g = e.Graphics;
DrawMyLine(g);
}
public void DrawMyLine( Graphics g )
{
if( goAheadAndDrawTheLine )
{
g.DrawLine( somePen, 0, 0, 100, this.numericUpDown1.Value );
}
}
private void DrawA_Click( object sender, System.EventArgs e )
{
goAheadAndDrawTheLine = true;
}
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
|
|
|
|
|
Hi!
I have a problem to convert a string "4.5" to a int.
I do like this:
double s1=(double.Parse(s.Substring(0,index),System.Globalization.NumberStyles.Any))*1.8532;
double s2=(double.Parse(s.Substring(index+1),System.Globalization.NumberStyles.Any))/10*1.8532;
Console.Write(s1+s2");
but is there a better way to do it?
/ Johan
-- modified at 13:47 Saturday 26th November, 2005
|
|
|
|
|
I assume that the variable index contains the index of the decimal point in the string?
Why not simply:
Console.Write(double.Parse(s, System.Globalization.CultureInfo.InvariantCulture) * 1.8532);
---
b { font-weight: normal; }
|
|
|
|
|
tnx Guffa..
I found another, not so nice, solution 
double vel = Convert.ToDouble(fix.Velocity.Replace(",","."))*1.8532;
|
|
|
|
|
When converting a floating point number you should always specify a NumberFormat or a CultureInfo, as the format varies depending on the culture.
If you have a number with a decimal comma, e.g. "4,5", you should specify a culture that uses that. For an example, in sweden we use decimal comma:
CultureInfo se = new CultureInfo(1053);
double vel = Convert.ToDouble(fix.Velocity, se) * 1.8532;
---
b { font-weight: normal; }
|
|
|
|
|
I don't understand your code. However, if I wanted to convert a string to an int, I would write the following code:
string numberString = "4.5";
Convert.ToInt32( Double.Parse( numberString,
System.Globalization.NumberStyles.Any ),
System.Globalization.CultureInfo.CurrentCulture )Then, you could use that int wherever or for whatever you needed.
Like, mutliply it by 1.8542?
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
|
|
|
|
|
Hi!
I have a DirectInput class where objects can bind specific keys so that they will be informed when the key state changes. But the Input class needs an identifier about who called the function "MapKey".
Right know I'm doing this:
public void MapKey(Key key, KeyEvent state, ButtonAction action, int who)
where who is the "ID" of the caller of the function. Right now each object uses "this.GetHashCode()" as a unique identifier. However, MSDN says: The default implementation of GetHashCode does not guarantee uniqueness or consistency; therefore, it must not be used as a unique object identifier for hashing purposes.
In C++ I think the best way would be to simply pass this as a void* parameter. What's the best way in C#?
regards
-- modified at 13:46 Saturday 26th November, 2005
modified 12-Sep-18 21:01pm.
|
|
|
|
|
You're right about the GetHashCode function. It should be unique for each instance of a class, not across the application.
If you have control over the classes that use the MapKey function, you could define an interface with a method and implement that across the classes that can use MapKey.
For example, define
public interface IIdentifiable
{
int GetWhoThisIs();
}Now, change your method's function to
public void MapKey( Key key, KeyEvent state, ButtonAction action, IIdentifiable who ) Finally, add IIdentifiable to your class' definitions, implementing a universal identifier system.
"we must lose precision to make significant statements about complex systems."
-deKorvin on uncertainty
|
|
|
|
|
That sounds good, thanks. I'll take a look at it.
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Greeeg wrote: In C++ I think the best way would be to simply pass this as a void* parameter. What's the best way in C#?
pass object ie:
public void MapKey(Key key, KeyEvent state, ButtonAction action, object caller)
xacc.ide-0.1 released! Download and screenshots
|
|
|
|
|
That's probably the easiest solution
regards
modified 12-Sep-18 21:01pm.
|
|
|
|
|
Hello,
This is a problem I've been having both with VS 2003 and VS 2005 Beta 2.
I want to assign the menu item "File" a shortcut "Alt + F". I also want to see the letter "F" underlined.
I type the following as the name: "&File".
The underline shows up in the Designer but not the form when the application is run. What am I doing wrong?
|
|
|
|
|
You're probably not doing anything wrong. This is an option controlled in the Display Control Panel, Effect's tab. Right-click the background of the Desktop, click Properties. Then click on either the Effects tab on Windows 2000, or the Appearance tab on XP and above, then click on the Effects button. You'll find what you're looking for in there.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
You're right! Thanks!
How obscure... 
|
|
|
|
|
i learned in school that we should always encapsulate private instances with getters and setters. but in practice, it tends to be an annoyance because i have lots of classes like this, which is much faster to type than the latter.
class Memory {<br />
object Value1, Value2, Value3;<br />
}<br />
how is that worse than the encapsulated version?
class Memory {<br />
object value1, value2, value3;<br />
public object Value1 { get { return value1; } set { value1 = value; } }<br />
}
all i could find is that the property version is slower because it has to invoke a method (albeit it'll probably never matter)...is there any reason i should encapsulate this, given i will very frequently be assigning new references?
|
|
|
|
|
hypermegachi wrote: all i could find is that the property version is slower because it has to invoke a method (albeit it'll probably never matter)...is there any reason i should encapsulate this, given i will very frequently be assigning new references?
The encapsulation means that you don't have to re-write lots of code, if at some point in the future you discover that you need to do some extra work in a getter or setter.
Getter example: You might decide later that it would be better to leave the field uninitialised and then have your property initialise it when it is first used. This is called a lazy-lookup. The value can be constructed, but it is an expensive operation to do so, and the usage patterns show that the value is not often needed - so why create it needlessly. So, essentially your property checks the field, if the field is null it creates the value and stores it in the field and returns the new value. If the field already contains a value then that is returned.
Setter example: You discover some time in the future that when you set the property that you need to carry out some other action (an analogy would be like a trigger in the database). So, since you have a property already, you can now put the extra functionality in without having to completely break your application.
Another Setter example: You could throw an exception if a value that was being set is out of range. Thus keeping the object in a consistent state. If you just exposed the field you would never know if some other object set the field to an invalid value and this is a potential source of bugs, especially the nasty sort that rear their head further on past the point that the bug was actually introduced. These are a real pain to track down and anyone having to maintain your code will not thank you for it.
In general, anything outside the class should not need to know anything about the internals of the class. If your class is exposing field members then you are exposing the internals of the class.
Finally, as to the view that using a property will incure the penalty of a method call then you should know that the compiler is smarter than you think. It will often inline properties and small methods for you so there is no penalty at all. If you are using VS2005 you can see this for yourself as there is support for debugging release assemblies and you can see optimisations.
Does this help?
My: Blog | Photos
"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious
-- modified at 13:24 Saturday 26th November, 2005
|
|
|
|
|
yep, makes perfect sense.
i have no experience looking through the IL code, and probably too lazy to do it. but i'm pretty sure anything other than the simplest of getter/setters, singleton null checks, etc. in properties will not be inlined.
what you speak of is true, in that properties allow for all of that extra work when needed. but if you know with 90% confidence that you won't need to do any checks or extra operations, why not just make them public fields as default?
and then, with the 10% of the time, if you need the extra operations, you can convert the fields into properties, without needing to change libraries that use it, since the syntax would be the exact same.
|
|
|
|
|
hypermegachi wrote: but if you know with 90% confidence that you won't need to do any checks or extra operations, why not just make them public fields as default?
Two reasons.
1. That last ten percent.
2. Because you screw the encapsulation of the object. You are allowing external entities know about the internals of the object. If at some future date you need to change that, you have a hell of a lot of code to fix that expects the internals of your object to look a certain way. Never ever underestimate the amount of work it will take to fix a problem like that. All it takes is 30 seconds (less if you are using VS2005 because it can automatically encapuslate fields for you if you want) work, that can save days or even weeks worth of work down the line. (If the project is large enough it might event save months of work)
hypermegachi wrote: with the 10% of the time, if you need the extra operations, you can convert the fields into properties, without needing to change libraries that use it, since the syntax would be the exact same
Not if you follow the guidelines they won't. Properties are always Pascal cased. That means that each word in the property name starts with a capital letter. Fields should be camel cased, which means that the first word is lower cased, each subsequent word is upper cased. So they won't have the same names. Also, some development shops have their own standards like prefixing fields with an underscore, or "m_" (harking back to MFC standards) and so on.
The bottom line is that if you want to be employable you must write code that is easy to understand and maintain. Maintenance costs can skyrocket on a badly written project. Making fields public, innocent as it might sound, is a step that will quickly make a project a maintenance nightmare. I certainly wouldn't want to have to clean up the mess, and neither would you - it is an almost soul destroying part of software development.
My: Blog | Photos
"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious
|
|
|
|
|
you're making the assumption that i'm accidentically exposing internal things. but i know for sure that i want everything to see...just like the Point struct.
btw, msdn doesn't say anything about fields in general, but it is very specific about the visibility.
private fields have nothing mentioned about them. this allows programmers to use hungarion, _prefix, or whatever they want. protected fields are camel cased (so derived classes don't get all confused with hungarion crap). and public fields are pascal cased to following everything else in the framework.
since i am following the guidelines, all my public fields are pascal cased, so converting to a property won't require you to refactor/rename every project that uses it.
btw, if you turn on xml, the compiler will warn you about all undocumented public fields as well.
|
|
|
|
|
hypermegachi wrote: just like the Point struct
This is incorrect. It is exposing the private fields x and y through properties called X and Y respectively. Check the IL yourself if you don't believe me.
I'd be very surprised if anything in the .NET Framework exposed its fields publicly.
My: Blog | Photos
"Man who stand on hill with mouth open will wait long time for roast duck to drop in." -- Confucious
|
|
|
|
|
sorry, i shoulda been more clear. i meant for my version of the Point struct i woulda been lazy and have public fields. nothing in the .NET framework exposes fields publicly, and so far that seems to be the only reason i can find in using properties over public fields.
|
|
|
|
|
hypermegachi wrote: i meant for my version of the Point struct i woulda been lazy and have public fields. nothing in the .NET framework exposes fields publicly, and so far that seems to be the only reason i can find in using properties over public fields.
No, there are lots of reasons for using properties over public fields. You just need to (re)read the replies I gave above to find some of them.
My: Blog | Photos
A stitch in time saves nine
|
|
|
|
|
if i didn't read your replies i wouldn't be able to give you a rebuttal for every point you mentioned.
perhaps you wanna read some articles/blogs that share my view...
http://www.devsource.com/article2/0,1759,1541911,00.asp
http://blogs.msdn.com/ericgu/archive/2003/11/12/52836.aspx
http://www.darronschall.com/weblog/archives/000149.cfm
i'm not saying that i'm right, and that you're wrong. i just don't see why people must follow such strict guidelines when other implementations which use less code satisfy the requirements, which is what ultimately matters (XP programmer at heart here).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
