|
You defined deviceControl as Control, which, if oyu look at the documentation for Control, doesn't have a IsConnected property.
You have to use the code you listed second, under "should I use this instead".
I suggest picking up a beginners book on C# and working through it. This is a very basic concept you're going to have to learn completely before building on it.
|
|
|
|
|
So, where does my answer fit in?
I'm halfway through a book I picked up at 'brainmeasures dot com'...
|
|
|
|
|
Truthfully? Not even close. Sorry, but you've got some more work to do.
|
|
|
|
|
Like I said, I'm only about halfway through my book…
I went back over the book, I didn't find anything in there talking about using properties on different data types…
There were a few examples, only on string and int…
Maybe, just maybe… It talks about using properties on different data types further in the book.
Also, I just got done scouring MSDN and couldn't find anything that talks about using properties on different data types…
I also click through the related topics and subjects, still couldn't find anything…
Could you point me to a place online or if you have time… Explain it to me here.
It would definitely be appreciated for your help.
I would like to learn C sharp the right way, I want to be able to write the code myself… I don't want to be a script kiddie!
|
|
|
|
|
Properties are just little bits of code that gets/sets a value or reference. You access them the exact same way no matter what the class exposing them is. Why use properties at all?? Property "setters" can be written to validate the value being passed in before it's used by the object. They can also be used to kick off other pieces of code, usually depending on the value being passed in.
Every class exposes it's own set of properties and methods. What each one does is explained in the documentation for that class.
For example, the String class, docs are here[^], only exposes two properties itself, Chars and Length.
I don't really know what your having a problem with.
|
|
|
|
|
I get all of that, "Black Box" type of writing code… Hiding implementation.
The only examples I've ever seen or talked about were on strings and ints… It never mentions other types like byte, long, boolean etc. etc.
My question is I guess:
can you use properties on all of those types?
|
|
|
|
|
Can you use the properties exposed by those types (don't use "on"), yes of course!
Using a property exposed by any type at all is exactly the same no matter what type it is.
|
|
|
|
|
I have been programming in C# for a long time. My engineer has programmed this way on the 1st option. I'm trying to figure out and need to revise the code to work with USB device. I've came up with the solution with loss/recovery of the USB device with WndProc process.
|
|
|
|
|
I have been programming in C# for a long time.
Then why did you ask this question? If what you said is true, this should have been obvious to you.
|
|
|
|
|
I would have to agree with the 2nd option.
|
|
|
|
|
|
Tried to cast the control. Still nothing.
|
|
|
|
|
You have to cast it to the type that contains the property your trying to use, not the one that doesn't.
|
|
|
|
|
Just to add to the other responses:
Your DeviceMonitor is a UserControl, which means that it is derived from Control (it has to be, otherwise it can't be displayed - even Form is derived from Control via a couple of other classes). That means it inherits (and you can access) all the properties of a Control in your class. But it doesn't work the other way...
DeviceMonitor devMon = new DeviceMonitor();
Control deviceControl= devMon;
this.Controls.Add(deviceControl); devMon contains a reference to your DeviceMonitor instance, so you can access all the properties and methods of the DeviceMonitor class via devMon:
if (devMon.isConnected)
{
...
}But deviceControl is a Control reference: it can contain a Control instance, or an instance of any class which is derived from Control, but it can only access the properties and methods of the Control class because that is the only class type it can guarantee that deviceControl contains. It is perfectly legal and correct to say:
DeviceMonitor devMon = new DeviceMonitor();
Control deviceControl= devMon;
this.Controls.Add(deviceControl);
deviceControl = new TextBox(); So the compiler will not let you access a derived class property or method via the base class variable.
It's a bit like cars: a Car has four wheels and an engine, but a Ford Fiesta also has Cruise Control, which a Ford Model T doesn't. If you declare a variable as a Car, then you can't access myCar.CruiseControl because the Car may be a Model T.
BTW: You don't need to use the deviceControl in your code - you can use a derived class anywhere you can use the base class. So this will work as well:
DeviceMonitor devMon = new DeviceMonitor();
this.Controls.Add(devMon);
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
|
Quite a performance hit if you do that a lot.
|
|
|
|
|
And what happens if that object does not have a property named isConnected? You have received some good advice here from people who are trying to help you, so why implement a bad answer from somewhere else?
Use the best guess
|
|
|
|
|
Heres one way:
DeviceMonitor devMon = new DeviceMonitor();
Control deviceControl= devMon;
this.Controls.Add(deviceControl);
...
if((deviceControl as DeviceMonitor).isConnected)
{
...
}
a better way:
DeviceMonitor devMon = new DeviceMonitor();
this.Controls.Add(devMon);
...
if (devMon.isConnected)
{
...
}
modified 31-Jul-13 17:37pm.
|
|
|
|
|
I have background threads that are doing things and based on logging when the computer goes to sleep, the threads cause the application to hang because of timing I would assume. I would like to abort the threads when the machine goes to sleep and bring them back when it wakes up, or something else if there is another way?
I tried inserting the code below yesterday, but I did not see any messageboxes below when I came in this morning and the application was hung again. This is my first time encountering power management issues, so I'm new to this override code.
Thanks for reading.
protected override void WndProc(ref Message m)
{
switch (m.Msg)
{
case WM_POWERBROADCAST:
switch (m.WParam.ToInt32())
{
case PBT_APMQUERYSUSPEND:
if (reminderThread.IsAlive == true)
{
reminderThreadTerminate = true;
MessageBox.Show("reminderThreadTerminate set to true");
}
break;
case PBT_APMRESUMESUSPEND:
if (reminderThread.IsAlive == false)
{
reminderThread.Start();
MessageBox.Show("reminderThreadTerminate started");
}
else if (reminderThread.IsAlive == true)
{
reminderThreadTerminate = true;
Thread.Sleep(2000);
reminderThread.Start();
MessageBox.Show("reminderThreadTerminate was still running, it was killed and then restarted");
}
break;
case (PBT_APMQUERYSUSPENDFAILED):
case (PBT_APMSUSPEND):
case (PBT_APMRESUMEAUTOMATIC):
case (PBT_APMRESUMECRITICAL):
case (PBT_APMBATTERYLOW):
case (PBT_APMPOWERSTATUSCHANGE):
case (PBT_APMOEMEVENT):
break;
}
break;
default:
break;
}
base.WndProc(ref m);
}
|
|
|
|
|
I moved the code to the areas below and it still froze this morning. If anyone has any ideas, I'd appreciate the direction.
case (PBT_APMQUERYSUSPENDFAILED):
//value passed when system is suspended
case (PBT_APMSUSPEND):
//value passed when system is resumed automatically
case (PBT_APMRESUMEAUTOMATIC):
|
|
|
|
|
Win 8/64 Visual Studio 2012 v.3, WinForms C#, FrameWork 4.5: no use of explicit threading in the project.
I've come to rely on using 'Stopwatch for a timer, and I am surprised to find, in a current project, a huge difference between what I observe, and what Stopwatch reports.
I have a very complex generic class, whose generic Types include other generic Type classes. I am able to create any number of instances of the outer class without a problem, and verify their contents.
Using Stopwatch to time the creation of the instances seems to give results consistent with what I observe. I'm not bothering, in this case, to do a "dry run" to pre-JIT.
Where what I observe really varies from what Stopwatch returns is: in the case where I loop through all the created instances in the outer class, and fill a StringBuilder with a complete kind of "report" on all the instances of the outer class, and all the various instances of the inner classes.
The inner classes have public Guid properties, set when their constructor is called (via 'private set).
If I create 10,000 instances of the outer class, and each of (in this case #2) of its inner classes have 10 objects each initialized as they are created. I end up with potentially 20k Guids, 100k each of the inner class contents. So, the resulting "report" (adding in tab characters, and other formatting) will come out to about 250k lines of text, containing about 4mb of characters.
From pressing the button that generates the "report" to seeing the report-TextBox filled, takes around thirty seconds, but Stopwatch is reporting the operation took 300~800 milliseconds.
Hypotheses:
1. there's something about using Stopwatch in the scope of a Button_Click EventHandler that leads to errors. Threading issue ? Doubtful, imho, since object creation seems to time okay.
2. there's something about using StringBuilder, and then converting to 'string, and setting the 'Text property of a TextBox that compromises Stopwatch. Wrapping TextBox refresh in 'SuspendLayout and 'ResumeLayout seem to have no appreciable effect.
Here's the code as stripped-down as possible to indicate how the report is being generated, and Stopwatch is being used:
sb.Clear();
watch2.Reset();
watch2.Start();
for (int i = 0; i < KVPList.Count; i++)
{
}
tbReport.Text = sb.ToString();
watch2.Stop();
tbEventReport.Text = "Report Displayed: Time(ms): " + watch2.Elapsed.MillisecondsAppreciate any suggestions, or ideas; very high-precision timing is not really needed here.
thanks, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
The problem isn't with Stopwatch at all. It's with sending 4MB of text to TextBox. Try opening a file that large in Notepad and you'll see the same result. It just takes forever for the TextBox to render something that large.
|
|
|
|
|
Dave,
I wonder what happened to you on this one: the general slowness of filling a standard WinForms TextBox control, or NotePad, with a large amount of Text is not relevant here at all.
How, I wonder, did such an inane response get three up-votes ?
The reason I am doing this stuff with showing a lot of text is related to software development; it has nothing to do with production mode, and some final software a user would interact with. I am examining the results of building a very large collection of a complex object, and that means I want to inspect the result in detail at run-time (much easier than setting a break-point in Visual Studio, and drilling down through little windows you have to scroll-in endlessly to reach item 899,233 out of 1 million).
The relevant issue is what I perceived as an inaccurate result using Stopwatch.
Alan's answer below points out the simple (and stupid) mistake I made in syntax.
Using Win 8/64, Visual Studio 2012 v.3, FrameWork 4.5, compiling to "AnyCPU," in Debug mode: using relatively old hardware (6420 CPU at 2.13mhz., 4gb. ram):
fyi: I can fill a TextBox with fifty-megabytes of text in around 33 seconds.
fyi: Using a RichTextBox I can fill it with fifty megabytes of text in under 3 seconds
fyi: converting a StringBuilder containing 50 mb. to a string: itself takes about 2 seconds.
fyi: NotePad ? I use UltraEdit, which can open a 50 mb. text file in under 3 seconds.
But, knowing someone with your skills can have an off-day, as I did; knowing you are imperfect, as I am: well, I feel less lonely 
your friend, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
My machine is a bit slower than yours. I can't do 50MB in 30 second.
But, you're correct. I lost my head had on this one.
|
|
|
|
|
A man who knows he lost his head, and gracefully admits it, is a man who has, not only a head, but a heart
appreciatively, Bill
~
“This isn't right; this isn't even wrong." Wolfgang Pauli, commenting on a physics paper submitted for a journal
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
