|
The compiler is correct. A Form doesn't define a lblFindWhat member. You need to cast search_form to the specialized type of the form you're using before accessing its lblFindWhat member.
/ravi
|
|
|
|
|
Please, don't set controls to public - it fixes the design of the form, because you can't change the label out without it affecting (and possibly breaking) outside objects.
Instead, create a public property which allows access, and set the label text yourself within the property. That way, you can replace the label with a more suitable control at some future date, and nothing gets changed outside.
In your search form:
public string Prompt
{
get { return myLabel.Text; }
set { myLable.Text = value; }
}
In your external class:
search_form.Prompt = "something";
The next problem is that a Form does not contain your controls. You have to cast it to an instance of your search form before the compiler can know what it contains:
foreach (Form form in this.MdiChildren)
{
MySearchForm search_form = form as MySearchForm;
if (search_form != null && (string)search_form.Tag == "BROWSE_PATIENTS")
{
search_form.Prompt = "something";
search_form.Activate();
is_form_exists = true;
break;
}
}
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Ugh. I should've just pointed the OP to your post. 
/ravi
|
|
|
|
|
 I do it all the time...
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
I'm still new, so I don't know if this is the best way to do what I am needing, and would like some feedback/advice.
I have a class that contains a double value. This double could represent a dollar value or it could represent a percentage value. Only one or the other, it will never have both. At runtime, I will need to be able to tell what type of value this is. Here is what I came up with, which appears to work, but if there is a better way, I would prefer that.
public class Rate
{
public double Value;
}
public class RateDollar : Rate {}
public class RatePercentage : Rate {}
public class TransactionLine
{
public Rate Amount;
}
myTransactionLine.Amount = new RateDollar();
if(myTransactionLine.Amount.GetType() == typeof(RateDollar))
if(myTransactionLine.Amount.GetType() == typeof(RatePercent))
For some reason, this seems like it is a clunky workaround. It also seems like it's possible for someone to create the value that is neither a RateDollar or RatePercent, and just as a plain Rate. Is there some way to prevent this, or is there a better way to accomplish what I am trying to do?
|
|
|
|
|
It doesn't make much sense to have a Rate class if all it does is contain a double. Is there more to it then that? Is the Rate used elsewhere? I'm gonna go out on a limb and say that TransactionLine should just have a double Rate property and a RateType enum property that says whether its a % or $ amount.
|
|
|
|
|
Thanks for the response! The enum seems like it would be a simpler way to handle this. Since the Rate may be used in multiple different classes, I think I should go with an enum in the Rate class.
public enum ENRateType { Dollar, Percent }
public class Rate
{
public ENRateType RateType;
public double Rate;
}
|
|
|
|
|
|
Thanks for responding!
I haven't really gotten to learning a lot about interfaces (or abstract classes), but I am thinking that will be the next topic I tackle.
The reason for this setup is because I am interacting with another software, and that software has one value that represents either a dollar value or a percentage. For example, this is how it would show a transaction:
Widget $12.00
Shipping $3.95
Subtotal $15.95
Tax 8.875%
Total $30.11
When I get this information from the program, they have a rate class that contains three members, an enum for the price type (dollar or percent), a double for the Dollar value, and a double for the Percent value. Because the line can only be a dollar or value and not both, one of the doubles will always be null.
I get the feeling (but I may be wrong) that they way they did their setup isn't the best. I will probably implement a Rate class that contains an enum and a double, which should work, but if there is a 'better' way to do this, I would prefer to learn about that type of implementation.
|
|
|
|
|
To me this information indicates you are "free" to change the Rate class in the program you get the information from: is that correct ?
The use of the phrases "They have," and "they did," and, "I am interacting with another software," is what gives me the idea you may not have freedom to change the Rate class.
thanks, Bill
"Everything we call real is made of things that cannot be regarded as real." Niels Bohr
|
|
|
|
|
Definitely would not use an interface here. Whats the point? Not everything needs to be an interface. Having 3 classes (or interfaces or whatever) just to hold a double is over engineering at its finest  .
|
|
|
|
|
|
Collin Jasnoch wrote: Because he has not stated his reason for layers but is trying to use it. That is
the point.
He did. He wanted to be able to tell the difference between a % and a $ amount. In which case an enum (or even a bool would suffice).
Collin Jasnoch wrote: I have seen cases where an empty interface is even used. It is not over
engineering. It is creating a base API.
By what the OP was an
interface is exactly what should be used.
OP wanted to have a single double that held 2 different types of values and wanted to know a way to tell the difference between them. Using his GetType() solution required having 3 classes. The enum solution requires an enum & a single class.
I'm not against interfaces, I use them all the time. I don't do stuff just cuz I can, I do stuff when its appropriate. I could also wear a tuxedo to go to Burger King, but I don't cuz that's slightly overkill .
|
|
|
|
|
A quick and dirty solution;
public class Rate
{
public double Value;
public override string ToString ()
{
string typeName = GetType().Name;
if (typeName.StartsWith(typeof(Rate).Name))
typeName = typeName.Substring(typeof(Rate).Name.Length);
return typeName;
}
}
It'd be cleaner to introduce a new property than to abuse the ToString-method. Putting an enum in there that returns "Dollar" or "%" would require the base-class to have knowledge thereof.
..unless you introduce an abstract property that returns an object. Yes, that introduces an extra cast in the calling code, but that could easily be wrapped in a utility-method.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks for the code! That would work as a temporary solution, I think!
It's sounding like I should really start looking into abstract classes/properties for this type of need! I haven't gotten that far yet in my learning, but it's going to be my next topic for sure!
|
|
|
|
|
hpjchobbes wrote: Thanks for the code! That would work as a temporary solution, I think!
You're welcome. PIEBald has an even neater solution btw 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I'd make Rate abstract and maybe make it a struct or replace the field with a read-only property.
hpjchobbes wrote: if(myTransactionLine.Amount.GetType() == typeof(RateDollar))
if(myTransactionLine.Amount is RateDollar
|
|
|
|
|
Lots of the responses here seem to be WAY over thinking things. 3 classes to hold a double value? Really? It doesn't seem like there is going to be any code in any of those 3 classes, so it should just be a single class with an enum indicating what it is. You aren't going to get around type checking all over the place. If you give us more info on what you are actually doing with the rates, we could provide more help. If its just for formatting, well, you would still have a single class and just override the ToString() that switches on the enum and formats with a % or $. And actually, the $ version should use the system formatter which formats currency according to the local settings.
|
|
|
|
|
SledgeHammer01 wrote: so it should just be a single class with an enum
A boolean would be sufficient.
|
|
|
|
|
I agree that a boolean would work fine, but an enumeration would be a lot easier to read. What if by some chance he has his requirements change and needs to keep track of more than two types for the value? This whole thing could go to hell really quick then. Seems like a lot of over engineering going on here
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
|
|
|
|
|
|
OP already explained what he wanted:
Quote: I have a class that contains a double value. This double could represent a dollar value or it could represent a percentage value. Only one or the other, it will never have both. At runtime, I will need to be able to tell what type of value this is. Here is what I came up with, which appears to work, but if there is a better way, I would prefer that.
He wanted a class that holds a double value and a way to determine the type of data. He thought the GetType() solution was clunky.
|
|
|
|
|
|
Collin Jasnoch wrote: That is not exactly what his post states
Looks to me that that is exactly what the OP said.
|
|
|
|
|
I would be more inclined to use the enum over abstract classes and interface for something like this. Unless there is a deeper level of programming that isn't being shown I would stick with simplicity.
This would be my interpetation of the object you are wanting also with a nice ToRateString() method so you can use the rate object to easily display your value in preformatted string.
Rate r = new Rate(ENRateType.Dollar, 5.58d);
public enum ENRateType { Dollar, Percent }
public class Rate
{
public Rate()
{
RateType = ENRateType.Dollar;
Value = 0d;
}
public Rate(ENRateType rateType, double value) : this()
{
RateType = rateType;
Value = value;
}
public ENRateType RateType {get; internal set;}
public double Value { get; internal set; }
public string ToRateString()
{
if (RateType == ENRateType.Dollar) return "$" + Value.ToString("0.00");
return Value.ToString("0.000") + "%";
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
