|
Okay, okay. Let me stitch you back up. 
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank you master! 
RageInTheMachine9532
|
|
|
|
|
Ok, this is starting to definately go off the bounds of programming! 
- Nick Parker
My Blog | My Articles
|
|
|
|
|
I have a custom component that is inheriting from System.Windows.Forms.UserControl. I would like to have the nice and consistent property Text rather than the property Caption.
Defining public string Caption works fine and I can view the property in design mode as expected. But if I replace the property definition with public override string Text, it doesn’t allow me to see the property.
What is the nuance that I’m missing?
Thanks
db
|
|
|
|
|
try public new string Text...
|
|
|
|
|
That's a bad idea. There is no reason to hide the Text property of the parent class and this will screw-up a lot of the implementation if the variables, fields, or properties to not specifically reference the derivative UserControl Type.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
And the world will end...
Nice to hear from you again!
|
|
|
|
|
It may. The massive power outage on US's eastern seaboard was caused by a simple bug.
The solution is very simple and examining the UserControl class using something like ildasm.exe would resolve the problem. The member is being overridden simply to hide it from designers and code editors. It was still available all along even without having to override it in order to show it again.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Probably written by a Californian.
Heath, I sincerely think that you need to RELAX. It may be the way I type, but you seem to treat things as way too important.
There is a radio show here in L.A. (yes, Lala land, home of Arnold the guvernor) where there is a guy who complains about everything and the question that everyone keeps asking him, and I ask you now, is "Who hurt you?".
PS: I forgot to admit that the bug in the electrical grid was mine, but being a Californian it was meant to run in the electical grid of Uzbekistan, and make the lights that were left on read out, "HS rules...", damn if I got it wrong again.
|
|
|
|
|
je_gonzalez wrote:
Heath, I sincerely think that you need to RELAX
I'm not the only one. I wasn't offended by your remark. A lot of things I post in this forum are for posterity in case some n00b ever considers searching this forum first.
That made me laugh. Oh well, here's to hoping... ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Let's see I was taught not to say RTFM to clients anymore two years before you were born. Yeap, things have changed, now is RTFF, as manuals have given way to forums.
|
|
|
|
|
It looks like you're declaring a field, not a property. There is a difference. Also, UserControl in .NET 1.1 attributes the override with the BrowsableAttribute and the EditorBrowsableAttribute to merely hide it from designers and source code editors. It's still there and you can still call it. They removed it only from view because UserControls are typically container in which Text make little sense.
To show it again, declare your property like so:
[Browsable(true)]
[EditorBrowsable(EditorBrowsableState.Always)]
public override string Text
{
get { return base.Text; }
set { base.Text = value; }
}You'll then see it again in both the designer and source code editor.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thanks. I was only using the Category, Description and Default attributes. Adding the Browsable and EditorBrowsable attributes did the trick.
Now that I've got it showing, testing has shown a couple other nuances.
1. Using Default doesn't do anything, it always contains the default object name as the default Text, regardless of the Default attribute. Even setting a line after InitializeComponent(); as Text="";, didn't do anything.
2. I would've been able to live with the Text property not being blank upon dropping the component on the form but not remembering its value just ain't cool. Initially I tried to use base.Text as the storage for the Text value (seemed the appropriate thing to do). Close the form and open it, the Text value is gone. Tried using a private variable instead, got the same result. Tried using new rather than override in both scenarios of base.Text and a private variable. The component still will not remember the value of Text. None of this affected Default either.
While answering this, can you tell me if there is a trick to finding info in the Help and/or SDKs? I suspect the answer you provided would've been there but, while there is probably everything I need to know at my finger tips, asking the right question seems to be the issue (thus RTFF seems to be a better solution than RTFM). Unfortunately, due to corporate bankrupcies I no longer have the team with which to collaborate (previously coded in Delphi) and some of the nuances of .Net have been somewhat frustrating to decipher.
Thanks again.
|
|
|
|
|
These are all design-time attributes. The DefaultAttribute is there to facilitate resetting the property value. Using a method that returns a bool called ShouldSerializePropertyName also facilitates this goal.
Again, though, don't use new. Only use this when you want to hide a member. For instance, if you use new, any code that refers to your class as a Control (where Text is defined as a virtual method) or any other derivative of Control (before your class), then the virtual Text is used. Only when a variable is declared as your Type will your Text be used. Since much of the Windows Forms implementation refers to all child controls as Control types, your Text accessors wouldn't be called.
To note (since you obviously read the little flame war that shouldn't have been), I don't completely advocate RTFM. RTFM goes well with RTFF, but I'm a strong believer in teaching a man to fish, if you know what I mean. Reading the docs and understanding them (like the mostly consistent naming conventions, how C# relations to .NET and IL relates to the CLR, etc.) is very important, but there's also times when people get stuck - even the best have brain farts now and then.
The best thing to do is just skim the class library docs some time. Get to know where everything is. Also, whenever you have a question about a specific class, the help Index is your friend. Just type it in. Don't specify certain properties, though, like ScrollableControl.Text because it doesn't exist as a defined method of ScrollableControl - it's inherited. It will be in the member documentation for ScrollableControl but not in the index. It's just the way their help built system works (and even those like NDoc[^] which I occassionally contribute to and is very popular).
Once you get to know where all the classes are roughly and how everything is named, it's not too hard finding what you need if you can't remember or even if you don't know exactly what you're looking for.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
this isn't directly c# linked as it can be applied to a lot of other languages, but there you go. when developing applications what do people normally name their versions as? major.minor.revision or also build number etc. i'd be interested to hear the standard or if there is one at all. also how do you cope with making patches (if you need to!  ) surely you wouldn't have to release a new program each time and send it?? can't you have some some of file that updates the original?
cheers,
surgeproof
-------------------------------------------------------
looking for hosting? ithium is good.
|
|
|
|
|
As far as version numbers go, that kind of depends on how you build the app. What I prefer, is to have a nightly build process with version numbers that are <major>.<minor>.<months><days>. Any builds outside of this would be the same, appending .<24hr time>, or some other unique identifier. The <months> and <days> represent how many months and days you've been working on the <major>.<minor> version.
If I'm not using a scheduled build, I usually just do <major>.<minor>.*, which lets .NET decide what the rest should be. For larger apps, or those with frequent changes, that don't have scheduled builds, I'd do <major>.<minor>.<revision>.*.
Michael Flanakin
Web Log
|
|
|
|
|
thanks, this helps. any ideas about the upgrade/patch routine? and also, do you name all the version yourself or incorporate it into the code? can't you type something like version.major in your code?
once again,
thanks.
surgeproof.
-------------------------------------------------------
looking for hosting? ithium is good.
|
|
|
|
|
You specify the version of the assembly using the AssemblyVersionAttribute. You can also increment the version of only the file - keeping the assembly version, which is what is used for Type references, the same to facilitate easier updates - by using the AssemblyFileVersionAttribute.
For instance, .NET 1.0 uses the assembly versions 1.0.3300.0, but the file versions (as of SP2) are 1.0.3705.228. If you examine your MANIFEST in your assemblies that target 1.0, you'll always see assembly references to versions 1.0.3300.0 for .NET 1.0 (1.0.5500.0 for 1.1).
All this is to facilitate side-by-side installation of both the .NET Framework versions and applications that use these versions. In many cases, applications can work on newer frameworks for which they were compiled so long as you don't use obsoleted functionality and don't use reflection to access private members (you may get lucky and it may still work, but it isn't gauranteed).
To learn more about versioning your apps - including how to redirect assembly bindings to newer or older assemblies, read the following articles:- How the Runtime Locates Assemblies (Step 1 especially)[^]
- Redirecting Assembly Versions[^]
- Creating a Publisher Policy[^]
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
thanks, this helps! 
surgeproof.
-------------------------------------------------------
Science without religion is lame, religion without science is blind. --Albert Einstein
The pioneers of a warless world are the youth who refuse military service. --Albert Einstein
A question that sometimes drives me hazy: am I or are the others crazy? --Albert Einstein
|
|
|
|
|
I'm not sure what the best solution for patches is. I would think that, if you have a modularized application, where you might have a bunch of DLLs and/or EXEs, you could have a patch that would replace whatever needed to be updated. Other than that, I'm not sure. I've never done a patch process before. Most of the stuff I've worked with has been either small Win Forms or Web Forms, which don't use patches - they just deploy the new version.
And, as far as setting the version, I'm not sure. I didn't do that part. I want to say that there was something that was based off of either the source control or build tool. NAnt is supposed to be a good build tool. I haven't played with it myself, but am hoping to get a chance to give it a good look.
Michael Flanakin
Web Log
|
|
|
|
|
Hi,
is it possible to have an transparent Label on top of a progressbar, so that I can still see the progressbar?
Setting the color of the label to transparent does not work - at least for me. The progressbar still is not visible trough the label, neither in the ide nor in the exe. Moving the label in front of another label will make it transparent - so it seems like a progressbar-related problem.
Any idea?
regards,
Dennis
|
|
|
|
|
not sure, i would've just thought you set it transparent like you've done. :s
-------------------------------------------------------
looking for hosting? ithium is good.
|
|
|
|
|
If your goal is display a message while the progress bar increments (like the percentage, which was common with older controls), you might be better off just extending the existing ProgressBar and provide your own painting by overridding OnPaint (do your drawing after calling base.OnPaint to make sure that the progress bar itself is draw first and your code gets drawn on top of it).
Getting the label to be transparent actually has to do with the parent forum in which it's contained. This only works in Win2K and newer (i.e., XP, 2003) since it uses layered Windows, "Windows" (or forms, dialogs) being the optimal word. A transparent color or alpha value is specified for the form an any control that uses the same color (ambience) down the chain of child controls is transparent/translucent as well. Since the ProgressBar is not a form and would paint in different colors anyway, that's one problem (the reasons go deeper, but I won't get into that).
Your painting method could be as simple as:
protected override void OnPaint(PaintEventArgs e)
{
base.OnPaint(e);
int value = (int)(Value / Maximum);
string s = value + "%";
StringFormat format = StringFormat.GenericTypographic;
format.Alignment = StringAlignment.Center;
e.Graphics.DrawString(value + "%", Font, SystemBrushes.ControlText,
(RectangleF)Bounds, format);
}This is untested, but should work and at least give you some ideas.
Microsoft MVP, Visual C#
My Articles
|
|
|
|
|
Thank you.
I already considered this solution, but still hoped for a Label-based solution.
Again, thanks for your help.
Regards,
Dennis
|
|
|
|
|
I have just joined a company that develops its own in house apps for call centre use but does not like using mice on the call centre floor. Has anyone got experience of developing .NET apps that do not use a mouse , but still use a winform based environment . If so , are there any big pitfalls to look out for ?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
