|
_awatts wrote: Previous version written in VB compiled as a Win32 app
So you can still run the device and observe actual good packets? That is good.
BTW: you should insist on good documentation! You did pay for the device, didn't you? So demand quality docs.
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
|
|
|
|
|
Go to this link and read the answer of that question.......
I think it will solve your all problems...........
|
|
|
|
|
Following is the general way to interact with your COM Port
try
{
sp.PortName = "COM1";
sp.BaudRate = 9600;
sp.DataBits = 8;
sp.Parity = Parity.None;
sp.StopBits = StopBits.One;
sp.DataReceived += new SerialDataReceivedEventHandler(read_data);
sp.Open();
sp.Write("AT" + Environment.NewLine);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
|
|
|
|
|
I've never had to do this before, and it's a Monday so my brain is not all here yet. I did try google first, but found nothing very helpful. I have a form application that can be started directly or via commandline passing a parameter, however, I need to debug the code in VS when I start it via commandline. What is the best way to do this?
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
Two ways...
Method 1: Go into the project properties, debug section, and enter the command line parameters there
Method 2: Start it manually, then do a Debug > Attach to Process... But if you do it this way, you miss the startup... You could always put a "Press any key to continue" at the start for debugging purposes.
|
|
|
|
|
Thanks Ian, the first method wasn't applicable because my program was called via 3rd party app that provided different commandline parameters so I couldn't do this. I was trying the second method, but I was missing the startup.
Ian Shlasko wrote: You could always put a "Press any key to continue" at the start for debugging purposes.
Is what worked for me.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
|
|
|
|
|
Glad to help
|
|
|
|
|
I have a plain XML data file that I want to read into a hierarchy of classes. I'm not sure how do do this. Can someone point the way?
Thanks
Everything makes sense in someone's mind
|
|
|
|
|
Well, if the XML tags correspond to class names in a predefined namespace, you can use reflection to invoke the constructors, then more reflection to assign child properties (Maybe have each class implement an interface so you know where the children go)...
Alternatively, you can use something like a factory pattern and recurse through the XML tree manually, which gives you more capability and flexibility while requiring a lot more code both at the beginning and when things change down the road...
Kind of depends on the specifics of the situation.
|
|
|
|
|
There are 2 levels in the XML, and I have classes for both. I'm defining the XML, so I can do this any way I want. I just don't know how to.
I was hoping for some method of automatically loading the XML into a class hierarchy.
Everything makes sense in someone's mind
|
|
|
|
|
Well if this is a load/save kind of feature, you could always just go with serialization. That won't give you very readable XML, but it makes things incredibly easy.
If you intend to create the XML files manually, I'm thinking you'll want something simpler and more flexible than what serialization would give you, so it won't be automatic.
|
|
|
|
|
Ian Shlasko wrote: That won't give you very readable XML
Why not?
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Have you ever used XML serialization? They throw in a ton of garbage tags, meta data, etc. to support various features. I wouldn't say its "unreadable", but you would definitely look at it and say "WTF!! why does this XML have so much crap in it?"
|
|
|
|
|
Then use the attributes correctly when creating your objects to serialize. You can also override the methods to create your own structure if necessary.
SledgeHammer01 wrote: why does this XML have so much crap in it?"
The answer is. It doesn't have to.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Beyond the "don't serialize this item" attribute? As far as I know, they still throw in *some* metadata. I could be wrong on that. Yeah, I guess you could reinvent the wheel and completely implement your own serialization without all the extra crap, but at that point, whats the point of using XML serialization? There are much better ways to store data unless you have certain requirements that push you to XML. Using XML because "thats what everybody does", is most certainly not a requirement  .
|
|
|
|
|
SledgeHammer01 wrote: Beyond the "don't serialize this item" attribute?
Yea, there are a few more attributes available. Have a look.
SledgeHammer01 wrote: I guess you could reinvent the wheel
No convincing someone with such a closed mind.
Have a nice day anyway
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Calm down dude. I was asking because I wasn't sure.
|
|
|
|
|
Like Sledge said... Namespaces, metadata, escape sequences... Annoying stuff you wouldn't want to see if you planned to edit it in notepad without needing to consult a reference every thirty seconds
But it's all a matter of the objective... For one of my systems, I use my own ToXML/FromXML methods to transmit trade data between the client and server. I don't use serialization, because I want to make sure I have full control over how fields are encoded, and how it behaves if a field is omitted or an extra one is found (In case the client is running an older version than expected). In other parts of the system, I serialize for simplicity.
Of course, it sounds like Kevin's situation doesn't need XML or readability at all, so this is all irrelevant
|
|
|
|
|
Ian Shlasko wrote: Annoying stuff you wouldn't want to see if you planned to edit it in notepad
Well XML Serialization wasn't meant to produce human editable files anyway, rather a means to transport information. But yes, it all depends on the usage and in this case the OP would probably be better off with Binary Serialization, or some other method.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Mark Nischalke wrote: Well XML Serialization wasn't meant to produce human editable files anyway
Which was exactly my point
Mark Nischalke wrote: But yes, it all depends on the usage and in this case the OP would probably be better off with Binary Serialization, or some other method.
Yep.
|
|
|
|
|
|
Ok, from your first post, I thought somebody is giving you XML that you have to read in. Now I see it is fully under your control. So I must ask: why do you want to use XML? Don't just use it because you *think* you are supposed to. Use it when its *APPROPRIATE*. It often isn't the right choice. People just think they are supposed to use it.
1) do you need it human readable?
2) do you need it human editable?
Before you answer those two questions, let me clarify... say you want to store application settings in an XML file? Your first answer might be "yeah, I want it totally human readable / editable". Why? Do you really want people going in and mucking around with your data files? Are you going to handle all the cases when it gets misformatted by a human? etc?
Now lets get to the real questions:
3) do you need platform interoparability?
4) is data size a concern? is performance? Remember, once your file grows to any reasonable size, xml becomes REALLY slow. At around 200k, it starts to slow down. At around 500k its quite noticable. At around 1MB, its 3 to 4 seconds of load time.
So, anyways, if you don't care about the human aspect and you don't need platform interoparability then XML is must definitely NOT the right choice. Especially if #4 is a concern.
Your best bet then would be binary serialization which is built into .NET as soon as you add the [Serializable] attribute to your class.
|
|
|
|
|
The only reason I thought of XML is because I want an easy way to store the data with the app. Their won't be that much data, and I probably don't want the user screwing with it, so I guess serialization is the best approach.
Everything makes sense in someone's mind
|
|
|
|
|
If you don't want the user to mess with it, then make it Binary. If the user sees something in "English", they might just be tempted to edit it with disastrous results.
|
|
|
|
|
Make it binary
Meaning encrypt it somehow? How would you make it binary?
Everything makes sense in someone's mind
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
