|
Hello Luc,
Thanks for the prompt reply and validating the approach.
What I understand from your comments in point 3 is:
3. I should keep sending the data from worker thread and let form append it?.
got it.
what I actually mean by point 3 beside this appending , I also needs to be quering on the form data For Ex: I have appended form text to 'Luc' and if textbox is not null and is 'luc' now do something else...
My understanding for the above is , to know the text of a text box any point of time , call a delegate from worker thread returning string with calling function on the form.
Is that right approach?
Secondly:
your warning comments mean what ? I did not follow that. please elobrate.
|
|
|
|
|
Hi,
what I meant was: make a clear split in functionality, try to define the work
in the worker thread with a clear border; it could be "take care of serial
communication", if so it would not know what will happen to the resulting data,
it would not have to know about the GUI, etc. That's a clean approach; and
later on you could reuse the worker thread's code.
But it you give it some other definition, that can be fine too.
The warning is this:
suppose the target (the other side of your serial cable) sends two strings
"aaaaaaaaaaaaaaa" and "11111111111111" one after the other.
Then it would be wrong to think you will receive first "aaaaaaaaaaaaaaa" and
then "11111111111111"; it might well turn out to be
"aaaaaaaaaaaaaaa11111111111111"
or "aaaaaaaa" and "aaaaaaa11111111111111"
or "aaaaaaaa" and "aaaaaaa11" and "111111111111"
That is, it is not because you are thinking about messages, that it will get
received as complete messages, the serial port does not care about anything
larger than a byte.
|
|
|
|
|
Hello Luc,
your points are well taken.
I should rethink my approach as My serial port management is real complex, to share with you, it's a controlling two device circuits boards through two serial COM ports simultaneously.
These device boards in turn needs to contol Weighbridges H/W like weighing scale, traffic lights, positioning beams etc.
My confidence is getting better after discussing with you.
Please stay tune.
Very best Regards.
Amarjeet.
|
|
|
|
|
Additional information on the messaging stuff:
when operating in synchronous mode and expecting text, you can do ReadLine()
to get an entire line of text; that's one way of dealing with textual messages;
of course you could use the synchronous mode in a background thread.
In case of binary data it seems you can't tell the system to return as soon
as a particular byte value gets received (although that functionality exists
in Win32).
|
|
|
|
|
Hi,
Ive got a filename that i'm passing to an stored proc, but the string is a filename:
string filename = "c:\\temp\\LogFile.Txt";
my command is built:
command.CommandText = "sp_UpdateLogFile '" + filename + "'";
however, sql doesnt accept the \\ directory seperators, they should only be one \.
Is there a function already available to remove these double slashes?
|
|
|
|
|
I presume your Stored Proc has a parameter, ie the filename
You should really add the file name as a parameter to the command object
ie
command.Parameter.Add("@FileName", fileName);
|
|
|
|
|
Replace[^]
filename.Replace("\\","\");
-- modified at 9:06 Friday 27th July, 2007
trash post, sorry!
All the best,
Martin
|
|
|
|
|
Or from within the stored procedure you can use something like this:
declare @test as nvarchar(40)
set @test = 'C:\\test\\rubbish\\file.asp'
select replace(@test, '\\', '\')
|
|
|
|
|
That will not do anything at all, as the string doesn't contain any double backslashes.
---
single minded; short sighted; long gone;
|
|
|
|
|
Martin# wrote: filename.Replace("\\","\");
That won't even compile. What you intended to write was:
filename.Replace("\\\\","\\");
or
filename.Replace(@"\\",@"\");
However, that will not do anything at all, as the string doesn't contain any double backslashes.
---
single minded; short sighted; long gone;
|
|
|
|
|
Sure!
All the best,
Martin
|
|
|
|
|
LOL, that wont compile
|
|
|
|
|
Mark06 wrote: sp_UpdateLogFile
Don't put "sp_" in the name of your stored procedure. "sp_" stands for "system procedure", and they are handled differently from normal stored procedures.
Mark06 wrote: sql doesnt accept the \\ directory seperators
First of all, your string doesn't contain any double backslashes. The backslash is the escape character in string literals in C#. When you put double backslashes in a string literal, the string will contain a single backslash.
Second, the database has no problems with backslashes in string literals. In MS SQL the apostrophe is the escape character, the backslash has no special meaning at all.
What has made you come to the conclusion that the database would have any problem with double backslashes, especially as your string doesn't even contain any?
---
single minded; short sighted; long gone;
|
|
|
|
|
Guffa wrote: Don't put "sp_" in the name of your stored procedure. "sp_" stands for "system procedure", and they are handled differently from normal stored procedures.
Specifically, SQL Server looks in the master database first, before looking in the database you're actually trying to use. This extra lookup doesn't cost a lot of time, but could break your application if Microsoft, or someone else, add a procedure with that name to the master database at a later date.
|
|
|
|
|
The backslash is an escape character within a string literal in C-based languages (C, C++, C#, Java), used to include non-printable characters within a string (for example, the newline character U+000A[^] is represented as '\n'). For that reason, to get an actual backslash in the string, you have to double it. This is processed by the compiler - in the compiled file, only a single backslash appears. Therefore you don't need to do anything to remove them at runtime - the compiler has already done it.
C# also supports @-quoted strings where the backslash is a literal backslash, not an escape character. The only escape available for this type of literal is "", which indicates that a single " character should be included in the string.
|
|
|
|
|
appologies, I was trying to keep it simple.
I'm actually calling the stored proc 'sp_attach_db'
and I've tried command.CommandText.Replace("\\",@"\");
but it didnt do anything to the commandtext value.
|
|
|
|
|
ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.NETDEVFX.v20.en/cpref2/html/M_System_String_Replace_1_d460c748.htm
use filename.replace("\\","\")
|
|
|
|
|
That's not surprising, both literals end up as a single backslash.
I suggest you post the actual problem you're encountering on the SQL/ADO/ADO.NET forum.
|
|
|
|
|
but this isnt an sql problem.
the problem is, c# setting a commandtext to "sp_attach_db N'c:\\temp\\logfile.txt'" when it should be "sp_attach_db N'c:\temp\logfile.txt'"
the actual sql command is irrelevant. its the double slashes thats the issue.
|
|
|
|
|
Mark06 wrote: the problem is, c# setting a commandtext to "sp_attach_db N'c:\\temp\\logfile.txt'" when it should be "sp_attach_db N'c:\temp\logfile.txt'"
It doesn't.
Why do you think that it would?
---
single minded; short sighted; long gone;
|
|
|
|
|
Damn debugger watch window (and tooltips) shows it as doubled.
|
|
|
|
|
Yup, that'll be it!! 
|
|
|
|
|
Visual Studio shows escapes in the C# debugger watch window and tooltips. I think that's a stupid idea, but there you are: that's what it does.
If you output the string to the console (Console.WriteLine) you will see that the backslashes are not doubled. If you're having trouble attaching the database, please ask on the other forum (including all error messages) - this is not the problem.
|
|
|
|
|
Never, never apply Console.WriteLine on a suspicious variable.
You might find the cause of a problem...
|
|
|
|
|
Mark06 wrote: I've tried command.CommandText.Replace("\\",@"\");
but it didnt do anything to the commandtext value.
Of course not. You are replacing each single backslash with a single backslash.
Also, the Replace method doesn't change the string, it returns the new string, so you have to use the result of the method:
str = str.Replace("\\\\", "\\");
Still, the string literal that you showed doesn't contain any double backslashes, so that will not have any effect at all.
What has made you come to the conclusion that the database has any problems with double backslashes, and why do you think that your string contains any?
---
single minded; short sighted; long gone;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
