|
Jun Du wrote: Any info or suggestions?
Yes, a thing called "research". Start here[^], and use a HttpRequest to fetch the desired byte-range. There might be an article on the subject, but I was to lazy to check 
--edit
Another downvote for the collection. Was it that really that annoying that I did not check? Here's[^] your article - you're welcome 
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
modified 12-Oct-12 19:43pm.
|
|
|
|
|
i want to change color.
If Groupbox enable fasle mode,.. then all text box, combo etc color change.
if Groupb box box enbale true,.. then no problem.
give me solution...
|
|
|
|
|
Hi,
Can you please clarify if the textboxes and comboboxes are located within the group box?
Cheers
Marco
|
|
|
|
|
textbox or combo with inside group box...
if inside groupbox control or not,
if define textboz1.enable=false;
then user define color not apply...
only enable false property does not take colour effect why?.
as like fore color, back color, border etc color and design effct.
other wise enable true,
user define color also runing on........
|
|
|
|
|
private void ReadDaqThreadProc()
{
dThreadCallback tcb = new dThreadCallback(ReadDaq);
while (flags.daqEnabled)
{
try
{
this.Invoke(tcb, new Object[] { }); }
catch (Exception e)
{
}
Thread.Sleep(50);
}
}
This snippet is part of a multithreaded app. "tcb" is a delegate, ReadDaq is a function in the MainForm code, and ReadDaqThreadProc is in its own thread. I know what the code does but I dont know how. I'd like to understand how this works. The line in question is the invoke line. Is 'new Object[] {}' an argument list for ReadDaq?
|
|
|
|
|
Yes, it's passing an empty object array (the default container for invoke-params) and calling "tcb", the ReadDaq method - a method without parameters. And it seems to swallow any exceptions, which isn't such a great thing.
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
It should be in a try block?
|
|
|
|
|
Member 8461599 wrote: It should be in a try block?
Why? Which exceptions does the Invoke method throw? It's only there to ensure that any exceptions from the implementation of the method do not kill the application; and those exceptions should be handled there - locally; not here. Also, it's wise to "log" all exceptions, as a "swallow all and be silent" is a known point of failure. Sometimes an exception is thrown away that you did not expect, causing weird program-behaviour.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
If you'll forgive my ignorance... I guess I dont know what you mean by "swallow any exceptions, which isn't such a great thing".
My knowledge of C# isnt very deep, as you can see.
|
|
|
|
|
This code:
try
{
...
}
catch (Exception e)
{
}is called "swallowing an exception", because whatever error occurs in the try block will be caught by the catch block and discarded without any attempt to handle it, log it, or in any other way acknowledge that there is a problem that should be fixed, or at least investigated.
This is considered a poor programming practice, as it just masks problems that may become serious later. There can (occasionally) be a good reasons for ignoring specific exceptions, but these should be restricted to specific exception classes (such as ArgumentNullException, or FileLoadException) rather than a blanket "Exception" and commented thoroughly.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Ahh... Gotcha.
There actually is code there. I took it out when I posted it here.
|
|
|
|
|
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
The exceptions which could arise in the ReadDaq function will arise in a different thread - the thread of the GUI. You are not able to catch them here, hence you can omit the try-catch-block here. But ReadDaq ought to have its own try-catch.
|
|
|
|
|
Bernhard Hiller wrote: You are not able to catch them here,
No, not quite true (at all). The Invoke mechanism catches an unhandled exception within the target method and rethrows it in the calling thread. In doing this the stack trace containing the site of the original exception is lost. Whether or not something bad happens when the exception is rethrown depends on the caller. For example I've noticed that the thread used by a System.Timers.Timer to call the Elapsed event handler carries on obliviously with no hint of discomfort!
See the remarks section in Control.Invoke[^]
Alan.
|
|
|
|
|
not 100% sure, but you could pass null instead of new Object[]{}. The signature of the Invoke method requires an object array. This is actually used to box/unbox parameters for the threading function. If null is allowed (I think so) this is for me preferable, because it indicates we're passing it to fulfill the method requirement. passing a new Object[]{} not only initializes memory, but also might indicate we "forgot" to do something.
Hope this helps.
|
|
|
|
|
String snmpAgent = "ipAddressOfPrinter";
String snmpCommunity = "public";
SimpleSnmp snmp = new SimpleSnmp(snmpAgent, snmpCommunity);
Dictionary<SnmpSharpNet.Oid, AsnType> result = snmp.Get(SnmpSharpNet.SnmpVersion.Ver1, new string[] { "OidOfPrinter" });
if (result == null)
{
MessageBox.Show("Request Failed", "Error", MessageBoxButtons.OK, MessageBoxIcon.Error);
}
else
{
foreach (KeyValuePair<SnmpSharpNet.Oid, AsnType> entry in result)
{
textBox1.Text = entry.Key.ToString() + " = " + SnmpConstants.GetTypeName(entry.Value.Type) + " (SysDesc.): " + entry.Value.ToString() + "->
here is the connection to the printer. I can get the name, properties, software etc. of the printer, but i cant get the status of the printer(if it is online, offline, toner level, paper status, etc.) can you help me to code this?
Thanks a lot for your ideas and helps.
|
|
|
|
|
Please do not repost the same question, particularly only two hours later!
It's rude, unnecessary, and unlikely to win you friends or get a better answer.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Please don't repost the same question; your question isn't more important than the others.
alexalexalex1907 wrote: can you help me to code this?
Coding it is your job, not mine. I can give you pointers, can help debug, or advise on code.
What you are trying to achieve is not something that many people will have experience with. So, asking it on a forum and waiting for an answer will be an exercise that might take a whole lotta time.
The protocol does not care about device-specific capabilities. You'll have to contact the vendor of your printer, and have them confirm that they actually SUPPORT this feature - as I said, there's a chance that the printer does not broadcast it's toner-status.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I'm getting the following sequence of exceptions:
First-chance exception at 0x791659f0 (clr.dll) in MyProg.exe: 0xC0000005: Access violation reading location 0x30383043.<br />
Unhandled exception at 0x30383043 in MyProg.exe: 0xC0000005: Access violation.
Does this look like a problem with the CLR, rather than with my code? This is all information I have on this exception because the call stack is messed up and I can't see where in the source this is happening.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: Does this look like a problem with the CLR
How to tell? The first message is a fairly common one seen when debugging and is raised when a DLL is needed and is not currently loaded. You can usually ignore such messages. The second one indicates that an access violation occurred somewhere within the program, which usually means that you have a reference somewhere that is going out of bounds. The only answer is a few minutes, or hours, with the debugger.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Quote: The first message is a fairly common one seen when debugging and is raised when a DLL is needed and is not currently loaded.
That's not the case. A first chance exception is the first phase in exception handling and is intended to support debugging. When an exception occurs the debugger (if one is attached) is given first chance at handling it (this first chance mechanism is part of the exception handling process and occurs for all exceptions). The debugger can take any number of measures including stopping it proceeding any further. If the debugger allows the exception to proceed normally or one isn't present it advances to the "second chance". This is the normal application level exception processing. There is no specific DLL not loaded exception in Windows that I am aware of.
Quote: First-chance exception at 0x791659f0 (clr.dll) in MyProg.exe: 0xC0000005: Access violation reading location 0x30383043.
Unhandled exception at 0x30383043 in MyProg.exe: 0xC0000005: Access violation.
Both these messages are caused by the same exception (note that both are access violations at the same address). The first line is the first chance and the second occurs after the second chance if it doesn't handle it.
Steve
modified 12-Oct-12 8:21am.
|
|
|
|
|
Quite right, I was confused and misinformed.
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard Andrew x64 wrote: Does this look like a problem with the CLR, rather than with my code?
No, it looks like an exception, and without anything to reproduce it'll be hard to place 'blame'. What version of the framework are you using? Did you install all the service-packs?
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
I need to disable my button because when the user presses it twice, I get an InvalidOperationException (backgroundWorker is busy and cannot run multiple tasks concurrently) in my form's code that is calling the form where I disable the button. In my btn_Program_Click method, I have
btn_Program.Enabled = false , so it should be disabled, but the user can still click on it for some reason. Perhaps I'm misunderstanding what Enabled = false should be doing??
Thanks,
Mich
|
|
|
|
|
An easier fix would be just to unhook the click eventhandler before you create your event and just enable your click again in the threading complete handler.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
