|
My CP Vanity article fills DGV cells with platinum, gold, silver, bronze. No problem, unless the cell is otherwise empty, then it may get tricky.
|
|
|
|
|
what is CP vanity.?? where is code?
|
|
|
|
|
It is one of my articles, as I said. And it has a download link.
|
|
|
|
|
I found an answer.
Using System.Drawing.ColorTranslator.FromWin32()
instead of ArgB();
|
|
|
|
|
I sometimes come across situations where I could use a string type to represent a unique key in something (sorry for being vague)...
An example:
ConnectSensor(new OffScreenSensor(),"screen");
Where the "screen" part is used to identify the OffScreenSensor object in a dictionary somewhere.
I could use an Enum as a replacement but was wondering if any one here has a better way of dealing with stuff like this?
I don't like the idea of having to look back to see the names of keys I have named before 
|
|
|
|
|
strings are fine for identifying, i.e. naming, objects by humans. And I would suggest you store the sensor's name inside the Sensor object, hence turn it into a constructor parameter!
|
|
|
|
|
Ok thanks, sounds like I am on the right track
|
|
|
|
|
Yeah, I would just derive a class from Sensor that manages its own name, something like a GUID for example.
|
|
|
|
|
Names are supposed to be pronounceable, IMO GUIDs aren't.
|
|
|
|
|
True... but why have a pronounceable name for something that doesn't need one?  .
|
|
|
|
|
venomation wrote: if any one here has a better way of dealing with stuff like this?
Depends on the context of 'screen'.
Do you use it as a display name anywhere?
Is it viewable by a user anywhere, like a config value?
Then you need to map to a different value in your code. Mapping of course could still be to a string value. The real issue however is that you want a programmatic value which will not change due to human concerns.
|
|
|
|
|
The idea is that other components can get another component based on its key.
At the moment there is no configuration file aspects, but I may consider it...
The problem is that one type of component can be added multiple times, some of them can be configured to act more generically, in theory I could install two OffScreenSensor's but with different keys.
|
|
|
|
|
That is a different problem however than using a key.
venomation wrote: some of them can be configured to act more generically, in theory I could
install two OffScreenSensor's but with different keys.
Which only apples to what I said if when you say "install" then it refers to something that is basically code, and not something that a 'user' would muck with.
If it does refer to 'code' then you are not using a "component" but rather an instance of a component. So the name refers to an instance even if most only have a single instance.
|
|
|
|
|
Its generally not a good idea to use strings as keys to get components like that. My boss is a notorious mispeller. Do you really want to spend time tracking down why your app doesn't work because somebody spelled it "scren" in 3 out of 100 places? GUIDs as I suggested earlier actually wouldn't be AS prone. Why? I'd probably type in "screen" myself because I can do that faster then copy & pasting from somewhere. With a GUID? I'm not going to type that in. Thats going to be a strict c&p.
Is adding a component multiple times "theoretical"? or is it really going to happen?
Would it be more practical to have a single instance of OffscreenSensor that can sense things from multiple locations?
Instead of doing something like:
Components["Screen1"].EventHappened +=
you could do something like:
IScreenSensor sensor = ServiceLocator.GetService<IScreenSensor>();
sensor.GetScreen(1).EventHappened +=
sensor.GetScreen(2).EventHappened +=
etc.
string keys are also prone to lazy search and replace issues .
|
|
|
|
|
SledgeHammer01 wrote: Its generally not a good idea to use strings as keys to get components like that. My boss is a notorious mispeller. Do you really want to spend time tracking down why your app doesn't work because somebody spelled it "scren" in 3 out of 100 places? GUIDs as I suggested earlier actually wouldn't be AS prone. Why? I'd probably type in "screen" myself because I can do that faster then copy & pasting from somewhere. With a GUID? I'm not going to type that in. Thats going to be a strict c&p.
I would suggest unit testing and system testing to solve that problem. Additionally that also solves the problem where they typed in "alternativeScreen" (a valid component) when it should have been "screen" (also valid.)
And myself I would be opposed to using a guid because that means that to figure out what component instance is in use one would need to look it up every time.
However depending on the actual requirements I would probably use a generated enumeration.
|
|
|
|
|
To add a key to a Dictionary, it must be unique. If there is a property of the Sensor object that is unique, use it in place of the made-up string. This will help you recreate the entire object from this key. If you just need a random string and you don't care about what it is, use a GUID.
|
|
|
|
|
If your goal is to make it easy for you to select one of the available, limited, set of choices of "unique keys" during development: then using an Enum makes very good sense: it gives you Intellisense display of the choices possible.
But that Enum could just as well be passed, as Luc pointed out, as an argument to a constructor overload or whatever for the OffScreenSensor class: unless, of course, you make use of that second parameter in other important ways in the function you call.
But, what's the usage/relationship of the new "OffScreenSensor" you create and pass as a parameter, along with the second parameter that serves a unique key to some (we assume) existing OffScreenSensor you are going to access by using the unique key?
That's what's puzzling here. Is the new "OffScreenSensor" some temporary entity that's never preserved: outside the scope of the functional call: never entered in your storage (dictionary or whatever) for the other (assume instances of ?) OffScreenSensor's ?
Are the OffScreenSensor instances in the (assumed) Dictionary sub-classed "flavors" of some master class OffScreenSensor ?
Is there a security aspect here ?
Without some sense of what your "big picture" goals are here, it's difficult to respond meaningfully.
In a technical forum like this, "vague" is automatically amplified
best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
|
|
|
|
|
|
Yeah, use an enum , or go for GUIDs
|
|
|
|
|
hi
i designed my form as
textbox, button
now in the buttonclick event i wrote a code which is as follows!
try
{
string constr = "User Id = scott;Password=tiger;Provider=Msdaora.1";
OleDbConnection con = new OleDbConnection(constr);
con.Open();
MessageBox.Show(" Connected to ORACLE!");
string q = "create table pert(enum number,ename varchar2(10),sal number)";
OleDbCommand cmd = new OleDbCommand(q, con);
cmd.ExecuteNonQuery();
MessageBox.Show("Table Created!");
}
catch (OleDbException a)
{
MessageBox.Show(a.Message);
}
now in the string q how do i add a textbox1.text so that while running my program i give the table name dynamically instead of statistically mentioning the table name as shown in the string q.
|
|
|
|
|
Perhaps with a parameter (I haven't tried it); certainly with concatenation, but that would be bad form.
|
|
|
|
|
was that an anwswer! its looking like something else!
|
|
|
|
|
with precautions, no bad form I'd say.
|
|
|
|
|
IMO the answer holds two parts:
1. don't use a TextBox, use a ComboBox (with ComboBoxStyle.DropDownList) presenting the allowable table names.
2. then perform string concatenation to build the SQL statement.
|
|
|
|
|
the dropdown list would eliminate the facility of having tablenames according to user choices. This IMO is essential if we are dealing with a SQL Parser or a simillar application, or a situation where we need user-specified entity names in the database.
We can use a textbox and employ reguler expressions / validation controls in order to eliminate the possibility of an incorrect tablename.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
