|
Think of the Application.Run() command as starting a loop that continuously looks for updates and messages from inside the form that it is running. Any code after the .Run() will not execute until you close the form that is open.
Thus, you must put code that you want implemented INSIDE of the the form that you created. So inside your WBScreen class, on your Form_Load (or constructor, or whenever you want it executed), place the code that you want to run.
|
|
|
|
|
Hi,
To add to what Phil told you, a Form normally is "event driven"; everything
it does, is triggered by some signal that causes it to execute a "handler".
Examples:
when the form is first loaded (so it can become visible), it executes a Load event;
if you add an appropriate OnLoad(...) method, that will run then (just once).
when you add a Forms.Timer that will cause a particular method to be called
periodically
when you add a SerialPort in your form's constructor, that SerialPort has a
DataReceived event, that could call one of your methods every time a specified
amount of data has been received.
A lot of the words in the above are keywords or even class/method names;
look them up on MSDN to get all the details.
I strongly suggest you get acquainted with Forms, Buttons, events and the like long
before you start working with the SerialPort class !
|
|
|
|
|
Hello Phil,Luc,
Thankyou very much for the guidance.
I did a brief study of what you sugested, article (http://www.codeproject.com/csharp/workerthread.asp ) states what you described.
I am coming up following approach mainly based on the link I have given above:
1. Create a worker thread in the form class which will liten to serial port.
2. Keep on apending the serial port data as and when received by a deligate to form.
3. To get the text of a form's control, Call a deligate in worker thread which will return string by calling a function in form class to get the control's text.
Please suggest.
Thanks and Regards.
Amarjeet.
|
|
|
|
|
Sounds good to me, with one comment:
"3. To get the text of a form's control, Call a deligate in worker thread which
will return string by calling a function in form class to get the control's text."
You could do the append logic in the delegate (and hence in the form class) itself,
so to the worker thread it would mean: "here is new data, deal with it",
and to form would take it to mean "I have got new data, I should append it to
the previous data and update the GUI".
Warning: the packets in which you will get data will be arbitrary, not necessarily
entire lines of text, or entire units of whatever data structure they represent.
|
|
|
|
|
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.
|
|
|
|