|
Check your application build settings, and change them from "any cpu" to "x86".
That will force it to build as a 32 bit app, and the WMP control should work.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Thanks for your reply ,in fact,I changed the build settings from "any cpu" to "x86",otherwise ,the app can't run.
|
|
|
|
|
Can I use finalizers as a backup for when IDisposable objects are not properly disposed?
I'll use a class that contains a thread as an example
public sealed class TaskExecuter : IDisposable
{
private Thread _thread;
~TaskExecuter()
{
if (_thread != null && _thread.ThreadState != ThreadState.Stopped)
{
_thread.Join();
}
}
private void Dispose(bool disposing)
{
if (disposing)
{
_thread.Join(1000);
}
}
public void Dispose()
{
Dispose(true);
GC.SupressFinalize(this);
}
}
So in this case, the class has a thread that it can reuse through the lifespan of the class. What I am concerned with is what if I or another developer creates this class, uses it, and forgets to dispose of it. This would leave the thread in an uncontrollable state and not to mention certain other system objects until the program is terminated.
Can I prevent this by making other checks in a finalizer?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
It can so long as your Finalize code doesn't mind being executed on a separate thread other than the one that created your instance and you don't care when the Finalizer gets called because you don't have control over it and it may take a good chunk of time after the object is flagged as dead before it gets called.
|
|
|
|
|
Ah, so would Thread.Join() throw an access exception if called in the finalizer? In the case that I working on, it doesn't matter when the finalizer gets called. I am just looking for ways to ensure that threads and other system objects get disposed of in the event that Dispose() does not get called before the object goes out of scope.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Access exception? Probably not, but calling Join in the Finalizer is definitely a bad idea.
|
|
|
|
|
Well, in that regard, I have another question. To explain a little more on the use-case that orginated this question, I have built a ThreadPool that spawns and terminates threads as it sees fit and it works well for that purpose. Up until now, I have been the only one to use that code but it might be making it's way into a larger library and I want to protect against the eventuality of a forgetful programmer. Is there a safe way to shut down those threads from the finalizer or is it better to safely abstract that away from the API?
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
OK, you're trying to protect the programmer from her/his self. It gets to the point where you're going overboard to protect someone who should know better. We all know (if we know what we're doing that is) if the object exposes a Dispose, you call it. Simple as that. Trying to make sure an idiot can use your code without issues just puts all of the work on you and none of the work on them, for what gain?
Can it be done from the Finalizer, sure. Is it a good idea? No. Can the user still run the system out of resources? Yep, because you cannot deterministically force a Finalize. The GC will get around to it whenever it feels like it and that may be AFTER the system has run out of a resource.
|
|
|
|
|
I see your point. Do what you can to ensure things run right but don't waste a lot of time on the what if scenarios.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
You should definitely read Eric Lippert's two blog posts on finalizers:
When everything you know is wrong, part one | Fabulous adventures in coding[^]
When everything you know is wrong, part two | Fabulous adventures in coding[^]
Particularly this part:
Quote: If you have a tree of objects and you are finalizing the root, then the children are still alive — because the root is alive, because it is on the finalization queue, and so the children have a living reference — but the children may have already been finalized, and are in no particularly good state to have their methods or data accessed.
Also:
Therefore, it is vitally important that finalizers do as little work as possible. Remember also that although all object pointers remain valid during finalization, it might be the case that those pointers lead to objects that have already been finalized and might therefore be less than useful. It is generally safest to avoid following object pointers in finalization code even though the pointers are valid. A safe, short finalization code path is the best.
And:
* Implement Finalize only if you hold unmanaged resources across client calls.
* Keep finalizer code simple to prevent blocking.
- Do not issue calls that could block the calling thread.
Basically, calling Thread.Join from a finalizer seems like a very bad idea. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Chapter 5 really helped to clear up some of my confusion with finalizers. I don't know why but it was easier to understand then the articles on IDisposable or garbage collection as neither of them really adequately explained the 'why' of the dispose pattern. I realized that if an unmanged resource is persisted for a lengthy period of time during execution, implement the Dispose pattern and put a Dispose call in the finalizer to ensure that any Win32 Handles (theads and such) get released back to the OS.
I also finally understand the reason for all those GG.SuppressFinalize(this) calls I've seen spattered about the internet. You put a backup Dispose() call in the finalizer but if you remember to call your normal Dispose(), the finalizer shouldn't be called because it would throw the ObjectAlreadyDisposed exception.
I swear, sometimes you can stare at the same articles on Garbage Collection and IDisposable dozens of times without parsing the whole concept together then one time, bang, "Oh, that's why it works that way!?" 
Thanks for the links. They were very informative.
if (Object.DividedByZero == true) { Universe.Implode(); }
Meus ratio ex fortis machina. Simplicitatis de formae ac munus. -Foothill, 2016
|
|
|
|
|
Hi Team,
I am working on unit of measure..
Just I want to know that logic part of the C#.Net source code for convert to Lb to Oz and Oz to Lb in drop down.
If you are selecting as LB in one of the drop down and one more drop down selecting as a Oz and total converting calculation will be displayed in one of the text box.
Please let me know how to convert this logic part.
I am struggling now this logic part in drop down.
Thanks
Somasundaram
I want to join in the website
|
|
|
|
|
1lb = 16oz
If you're converting from lb to oz, multiply by 16.
If you're converting from oz to lb, divide by 16.
(Assuming you're not using Troy pounds/ounces[^].)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
There's no real "logic part" in the operation: it's all about identifying what the conversion factor is.
I'm just guessing that you're a beginner and this is homework - so I won't explain how I'd do it (it probably involves some bits you haven't got to yet) and suggest that you pick a "base unit" and provide each possible "convertable unit" with a value which converts to that base unit. For example, if you select the kilogram as your base unit, then the conversion factor for 1lb would be 2.20462, and the conversion factor for 1oz would be 35.274
So to convert from "unit a" to "unit b" you multiply the number of items by the "unit b" conversion factor, divide that by the "unit a" convertion factor, and round it to perhaps 2 decimal places.
If the number of lb is 6.0, then you would convert to oz by:
6.0 * 35.274 / 2.20462 = 96.0002177246
Rounded, that's 96.00 oz.
So all you need to do is write a method which takes the selected unit text, and returns the conversion factor. Then call that twice, and you're pretty much there!
Try it: it's simpler than it sounds!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
THREE YEARS!
And he can't do that on his own?
Elephant! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Be fair, he said it was three years in the field. Very possibly there was no computer in this field. Perhaps there were some sheep.
This space for rent
|
|
|
|
|
Even the sheep could have worked it out by now! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
And the profile is 9 years old so it could mean that he has been around for 12 years
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If you are really "working on unit of measure", you should take a moment to consider the longer term; e.g. a "weight structure / class".
The weight could have a "native" value, but would have methods for returning different UOMs: all ounces or grams; or pound / kilogram fractions; etc.
public class MyWeight {
public decimal Weight { get; set; }
public UnitOfMeasure Units { get; set; }
public MyWeight( decimal weight, UnitOfMeasure units = UnitOfMeasure.Pounds ) {
this.Weight = weight;
this.Units = units;
}
public decimal InPounds( int decimalPlaces = 0 ) {
decimal qty = 0M;
switch ( this.Units ) {
case UnitOfMeasure.Pounds:
qty = Weight;
break;
case UnitOfMeasure.Ounces:
qty = Weight * 0.0625M;
break;
case UnitOfMeasure.Kilograms:
qty = Weight * 2.20462M;
break;
case UnitOfMeasure.Grams:
qty = Weight * 0.00220462M;
break;
default:
throw new NotImplementedException( string.Format( "{0} to Pounds.", Units ) );
}
qty = RoundUp( qty, decimalPlaces );
return qty;
}
modified 2-Jun-16 11:09am.
|
|
|
|
|
Hello engineers
I'm Alireza Ketabdari,
I need a component for design of UI(user interface) with C# language that has a 2 main feature:
1- draw polygon and points and lines by setting location of these in code.
2- change location of these when program is running by click then moving the mousse(main feature).
I could draw polygon and lines and points in panel component but Its locations couldn't change by click then move mousse.
If you know the component that provide me these two feature, you can help me very much and I appreciate you about your help and your attention.
Tank You
|
|
|
|
|
This sounds a lot like homework!
So what have you tried?
Where are you stuck?
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
It's called a "frame".
You "change locations" by "redrawing" the shapes and lines each time you have new coordinates.
Simply changing a "coordinate" usually has no "visual" affect unless you consider how the particular type of window you are working with "renders" its UI (i.e. measuring; layout; updates).
|
|
|
|
|
There is rarely a component that does all you require out of the box, and in the few cases it does, it is often rather expensive.
I'd recommend using a Panel
Member 12560979 wrote: I could draw polygon and lines and points in panel component
In that case, you can also create a new Panel (or PictureBox or whatever) and put it in that location, right? You'd need the coordinates (which you got), and add the thing to the controls-property of the panel. Things are easier if you give them different colors.
Something like;
var p = new Panel { BackColor = Blue, Location = new Location(x,y), Size = new Size(10, 10) };
Form1.MainPanel.Controls.Add(p);
This would give you a non-transparent panel on top of another. You could override the painting-event in the panel you added, only drawing the desired line. Moving the panel can be done by hooking the mouse-events of the child.
You could take a look at Paint.NET, Google for such examples and/or post more here if stuck 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
I have been banging my head for quite sometime over my unit test problem (MSTest VS2012). For some reason all of my test methods are grayed out with white exclamation points in front of them and they can not be selected.
When I do a Clean then Rebuild, the test methods could be selected again. However, when I click Run All, it hangs without crashing or giving me any errors. Eventually I just had to hit cancel.
Please suggest how to fix this issue, thanks.
modified 2-Jun-16 2:57am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
