|
This sounds like it can be done with a ListBox or something similar, data bound to the result of the query. The rows of a list box can be complex controls (or groups of controls), by changing the ItemTemplate.
|
|
|
|
|
Thank you all for your assistance
|
|
|
|
|
I want use dll to create a program that can received sms from
mobile and do something;
1-which dll can I used?
2-which mobiles can supported?
pls i want quick answer ;
note : the mobile connected with computer by a USB cable;
I use C# 2010;
modified 25-Oct-12 6:02am.
|
|
|
|
|
Saied Ghazal wrote: pls i want quick answer
That's rude.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
If you want quick answers then there are three things you should do:
1) Don't use a subject like "Hi All" - it tells us nothing about your problem and is thus a complete waste of time - yours and ours.
2) Don't damand a quick answer - that is rude (as has been mentioned) and thus can delay answers rather than encouraging them. Remember that you do not pay our wages even indirectly, so you are not in a position to demand our attention.
3) Try google. It is quick and easy - heck even my wife can use it - and if you try even a little bit you can find an answer without working up a sweat. I did - it took about 20 seconds to find a page with relevant info starting with a text string copied from your question.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Here[^]
read it and update this post.
|
|
|
|
|
Greetings Members Of Code Project,
Zero Clue King here; eagerly awaiting clueless newbee status.
This is my first post; so apologies offered in advance for any perceived idiocy or ignorance of the prevailing protocols.
The question: I want to click one button, and send one byte across a serial port.
I want to do this in C#
I'm currently reading, "Basic serial port listening application By Amund Gjersøe" from two years ago on another page on this site.
I have my app set up in Visual C# (I think it's 2010) with some buttons, a combo box, and a serial port. Not sure how to post a screen cap, etc.., probably not even needed.
I can open the port, close the port, give it a name, etc.. The moment I try to do anything that has anything to do with the word "write" it seems that C# changes from nice to malicious.
I just want to get a grasp of the elementary concepts behind sending a byte out the serial port.
We'll get into multi-threading and such things later. For now, I would like to focus on the brass tacks of sending one byte out the serial port.
This is the thing that is most confusing to me: I want to send an honest to goodness byte, just 8-bits, and nothing else. It probably will not be ascii text. In fact, I know it won't be for the first several times.
After I get one byte out, I will want to get more fancy and send various combinations. For the moment, just one byte is the goal.
Again, newbee here; don't know one thing from another, so searching is not a polished skill at the moment.
I want to assure any reader that I have indeed searched via Google, Bing, and Yahoo, and MSDN, and YouTube tutorials, and Plan Nine, and everywhere. It appears that SEO has rendered their results as mostly obfuscation these days; desperate to make buck, I guess.
I am astounded that this little task doesn't have several tutorials and code examples floating all around the internet.
|
|
|
|
|
C-P-User-3 wrote: I am astounded that this little task doesn't have several tutorials and code
examples floating all around the internet.
Actually, there's tons of them. Such as this one[^] and this one[^].
There are two common problems people run into. The most common is that they don't set the serial port up with the correct communication parameters, such as baud rate, bits per byte, number of stop bits and parity. You can't just set whatever you want on your side and expect the other side to understand.
BOTH sides have to be setup with the same parameters.
The other most common problem is using a cable with the wrong pinouts. That also has to be correct otherwise you'll be sending data on the correct pin on your side, but going to the wrong pin on the other.
|
|
|
|
|
Thank you Dave and Gerry for your feedback.
My original post was long enough as is (as was ?) so I didn't want to jam in any additional details.
The wires are working.
I am (totally) confident of the physical wires and connections, because I have been using them with various software packages to send and receive data from an external embedded system. Those packages have demonstrated successful sending and receiving from the device; as in,,,
--- I send out a specifically formatted group of bytes
--- The device responds with the proper sequence of bytes
i.e., things are working fine and it's time for me to get on with the user interface
I have pretty extensive control over the external box; to the point of single stepping the CPU instructions if I need that.
I can set up the UARTs (the external box has several of them) to generate an interrupt (i.e., an int in the external box) when various things happen; including the reception of a byte. If the byte is no good, it typically means that the frames are wrong, and even more typically almost every time because the start/stop/data/parity settings are off. When the speeds are out of whack it gets downright bizzare (as one would expect).
So, with that in mind, I want to assure you that I have indeed done much more than a loopback test in Hyperterminal: I've used these very machines and these very wires to communicate with the device being developed.
But then again, yes, that's the first culprit when bytes don't go across.
Gerry Schmitz wrote...
"...one typically doesn't just "send"; ... almost always a "response" ..."
Correct.
Walk before we run.
This is why I want to develop one app that just sends one byte as the result of clicking one button just one time.
The examples I've seen here are almost universally embellished with extensive controls, boxes, etc., and that's great.
My point is that by focusing on the bare minimum, at the start, the process of reading, turns to writing, turns to observing, turns to practicing, turns to refining, turns to learning, and ultimately turns into understanding.
The fully functional app is not good for that at all.
Dave Kreskowiak wrote...
"...Actually, there's tons of them. Such as this one[^] and this one[^]...."
Correct, and that's where the learning curve goes vertical, or even Bezier, as in backwards or way off the path of the desired goal.
Yes, they contain the specific concept that I want to explore, but that concept is enshrouded with lots of other stuff (which I totally understand; they want to demonstrate a working useful app; not a specific isolated single concept) which requires ancillary and extraneous factors. This is what thwarts learning; at least for me: i.e., hiding the trees in the forest.
The "forest", in this case, is the C# vocabulary. The trees all look alike, so you can't find the one you want. In like manner, the specific syntactical invocation of the method/class/whatever is hidden because of the interactions of the seventeen other things the application has to do.
Yes, you are correct, nobody on earth is going to buy an app that sends one byte out the serial port when you click one button.
However, I believe that that "app" would be exactly the first one that should be studied by anyone who really wants to understand the construction of a C# user interface that is communicating with a device outside the computer.
More to the point, in one of those examples, I find a line of code which is exactly what I want to do, Here's that line...
// Write a set of bytes
port.Write(new byte[] {0x0A, 0xE2, 0xFF}, 0, 3);
So, I think, "Yes, that's what I want" and try to put something similar in my code. Nope, errors. So I try cutting and pasting that exact line, verbatim. Again; Nope ! When I attempt to put it into my code, total Ka-Bong, life goes fail, fail, and more fail.
Again, I can set up my external box to interrupt me when I get the first byte from its UART, and I'm also quite confident of the physical medium connecting it based on consistently observed behavior established over several months now; I'll just toss out a guess of 10 million bytes properly transmitted and received.
I hope this is not rambling or needless philosophical debate.
I'm just trying to write an app where I click one button one time and get one byte out of the serial port.
Following true engineering psychology, nerds everywhere jump on anything simple and immediatly go, "Oh boy ! That's easy ! Let's add fifty steps of complexity to the problem !", which is what I sortta'kinda see happening everywhere I ask this question.
If I don't miss my guess, the final stuff here will be less than twenty lines of code when I get it figured out and actually type them at the keyboard.
Perhaps this is where we could really...
[A] help me, a lot and
[B] increase the popularity of this site.
I want an idea of the twenty lines of code that will send one byte when I click on one button. You have hundreds, thousands, maybe millions of lines of code here.
Can you show me the ones that I want right now ?
|
|
|
|
|
|
Thanks Dave,
I clicked on the link and arrived on this page...
http://msdn.microsoft.com/en-us/library/y2sxhat8.aspx
... Which has the title, "...SerialPort.Write Method..." I find this sentence...
"...By default, SerialPort uses ASCIIEncoding to encode the characters. ASCIIEncoding encodes all characters greater than 127 as (char)63 or '?'.
That is absolutely not what I want.
The next sentence after that says...
"...To support additional characters in that range, set Encoding to UTF8Encoding, UTF32Encoding, or UnicodeEncoding...."
I made the guess that I did *NOT* want UTF32Encoding, or UnicodeEncoding, which left the one choice of UTF8Encoding.
I clicked on that link and came to this page....
http://msdn.microsoft.com/en-us/library/system.text.utf8encoding.aspx
...which had the title, "UTF8Encoding Class".
That class has 3 constructors, 13 properties, and 33 methods.
The 11th of those 13 properties is, "IsSingleByte", which led me to believe that that might be of interest to me. The description of that property read as follows...
"...When overridden in a derived class, gets a value indicating whether the current encoding uses single-byte code points. (Inherited from Encoding.)..."
The word "Encoding" was within a href link as well, so I had to choose which to view first. The "IsSingleByte" looked most likely, so I clicked on that link.
That click to me to this page...
http://msdn.microsoft.com/en-us/library/system.text.encoding.issinglebyte.aspx
Which had the title, "...Encoding.IsSingleByte Property..."
This seemed to be a property with a boolean [True|False] value. An example is present on that web page. The results are all "True" and "False" values, so this may or may not be relevant to my interests.
On that page, I saw this blurb...
========================================CLIP========================================
Caution
You should be careful in what your application does with the value for IsSingleByte. An assumption of how an Encoding will proceed may still be wrong. For example, Windows-1252 has a value of true for Encoding.IsSingleByte, but Encoding.GetMaxByteCount(1) returns 2. This is because the method considers potential leftover surrogates from a previous decoder operation.
========================================CLIP========================================
...so I just sat there and wondered what thoughts were in their mind when they wrote that.
If I knew what "Windows-1252" was I might understand more (as of this writing, I'm still using Win'7, hoping the boss will buy me Win'8).
After that, I returned to the previous page from which this link was acquired to look at the "Encoding" link.
I arrived at this page...
http://msdn.microsoft.com/en-us/library/system.text.encoding.aspx
...which had the title, "...Encoding Class..."
There were 2 constructors, 21 properties, and 33 methods.
Of the 21 properties, the 15th was "IsSingleByte", the same link I had earlier clicked, so I didn't want to follow a circular paradigm.
The 19th property was "UTF8" with the description "Gets an encoding for the UTF-8 format" so I guessed that that might be it. I clicked and arrived at this page...
http://msdn.microsoft.com/en-us/library/system.text.encoding.utf8.aspx
...Which had the title, "...Encoding.UTF8 Property..."
Where I read, "...This property returns a UTF8Encoding object that encodes Unicode characters into a sequence of one to four bytes per character..."
That is, again, exactly and precisely what I **DO**NOT** want. I want to send out UN-encoded bytes; just regular 8 bit values.
So, I am encountering circular logic with no end and no answer. I could really use some advice on how to send one byte (any one of 256 possible values) by itself, without encoding extra bytes to go along with it, out the serial port.
Does C# provide such a capability ?
|
|
|
|
|
|
As Dave pointed out, there are any number of components and / or settings that can be at fault.
I typically tell my users to start with a configuration that works, and then start swapping components in and out in order to create a new setup; as soon as things stop working, you will know what component / setting is at fault.
That said, if you're starting from scatch, then it might be worthwhile to start here (Google the following):
"Performing a Loopback Test in Hyperterminal".
(And one typically doesn't just "send"; there is almost always a "response" expected from the other device once a connection has been made).
|
|
|
|
|
Thank you Dave, and Gerry, again.
Now I feel really stupid.
Windows was lying to me.
The reason the byte wasn't going across the port was because somebody (not sure who) was lying to somebody (again, not sure).
This line returned the port in question...
string[] The_List_Of_ComPorts = SerialPort.GetPortNames();
The result was a big lie. The given port wasn't there in the first place, despite the fact that Windows did report it, did return it to the function call, and the port name showed up in The_List_Of_ComPorts.
This one was beyond my ability to recognize immediately.
For future reference, and perhaps to help the next victim like me, the fix that worked this time with Win'7 was...
-- Close down C#
-- Windows, Start button
-- Control Panel
-- Device Manager
-- Ports (COM & LPT)
-- Delete any com port that isn't physically wired
-- -- (This probably means COM3, COM4, COM5,,, COM99, etc.)
-- Exit everything
-- Restart computer
-- Reconnect the USB-Induced serial ports
-- Let them do their driver stuff
-- Invoke your C# IDE again
-- Watch this line execute...
The_Chosen_Serial_Port.Write(new byte[] { 0xFF }, 0, 1);
Then you will be happy for the rest of your life and there will be world peace and prosperity for all humans everwhere.
Dave, Gerry, again, I thank you. I am embarrassed and even more annoyed by such an oblique problem.
|
|
|
|
|
Yes; you are now on your way.
In a nutshell, GetPortNames() uses the Windows registry; which may have no relationship to what is actually connected. And as you have noticed, you can “open” these phantom ports; but any other operation will fail.
When in doubt, one should always use the Control Panel to verify what the operating system has actually detected in terms of hardware.
Here’s a “fun” one you might one day run into if you use a USB-to-RS232 converter and the driver is not “smart” enough:
A customer installed a USB-to-RS232 converter, but the driver, instead of using a “free” port, used the one previously assigned to a serial mouse! Anyway, (if one had noticed) Windows now reported that it had found new hardware (a serial mouse!) and any time the device (a temperature controller) attached to the USB-to-RS232 converter sent back data, the mouse cursor would move about and perform random clicks on the desktop or on whatever was on top, popping up menus and what not.
(Some drivers will only try to use say COM1 thru COM3; and woe be to you if these are already assigned).
|
|
|
|
|
Hello everybody,
I created application in C# on VS2010 and Windows 7, which use direct sound reference. Now I want to carry over exe file on PC with Windows XP. What should I do for running app - install NetFramework and? Or what problems can I expect.
thanks, Sam
PS : The PC dosen't have Internet connection, so I must to have all prepared.
|
|
|
|
|
Well, you'll have to make sure that you haven't targeted a feature in DirectX that isn't available in XP. The version of DirectX that ships with Windows 7 is a higher version than the one that you install on XP. And yes, you'll have to have the .NET Framework. If you use the Visual Studio installer to create a package, it should give you an indication of what else is needed and you can add the as merge modules if necessary.
|
|
|
|
|
You need to make sure direct sound dlls are either installed on your machine or install install them via a setup project.
|
|
|
|
|
Starting a new desktop application, I wonder whether I should stick with WinForms or try to learn WPF.
On the one hand, the application is quite simple, GUI-wise, and has no need for any blending or animation or other 'cool' things. It's a form-based application, of the classic type that's been a Windows staple for 20 years.
On the other hand, I've seen claims that WPF is the future.
Mind you, Win7 is only now being picked up, and Win8 still supports old desktop applications. Learning WPF as a gateway to Silverlight seems a bit pointless now that SL seems to have been dropped. It's also unlikely I'd try to migrate this app to the cloud - if I did, I'd probably re-write it in PHP or Python.
So that leaves WinRT. Is that the only reason for jumping to WPF?
(I should probably note that this is a hobby project - in my day job I'm a C++ developer, which I'm happy with, so I'm not interested in learning WPF to "further my career". I tend to write GUI-based applications in C#/Winforms though, as MFC is a dog.)
Grateful for reasoned advice.
|
|
|
|
|
Unless you want to learn WPF for some other reason, if you already know WinForms, it seems like it will do the job you want fairly straightforwardly so I would just use that. WPF lets you do lots of cool stuff but if you don't need any of that then it doesn't add all that much (data binding is a lot better but that can be worked around).
Orjan Westin wrote: On the other hand, I've seen claims that WPF is the future.
Other things that have been 'the future' include SVG, Silverlight and applications in the cloud.
|
|
|
|
|
The answer really depends on whether or not you see yourself moving towards writing Windows Store style applications (possibly the crappest name for a tech stack ever). If you are happy writing desktop applications and will continue only writing desktop applications then WinForms is a fine choice. If you see yourself wanting to write TTSFKAM (The Technology Stack Formerly Known As Metro) then knowing WPF will certainly help.
|
|
|
|
|
I suspect I'll have some other things later on, more suitable for TTSFKAM, but I'll burn that bridge when I get to it. 
|
|
|
|
|
Orjan Westin wrote: On the other hand, I've seen claims that WPF is the future.
Microsoft stated that WPF is not a replacement-technology for WinForms. Contrary to the claims, it is not a dead technology. VB6 is, and even that still runs on Win8. Somehow I don't think you have to worry much on the platform going away
Orjan Westin wrote: So that leaves WinRT. Is that the only reason for jumping to WPF?
From what I heard, WPF does a nice job on decoupling the form from the code. A nice comparison can be found here[^].
Bastard Programmer from Hell 
if you can't read my code, try converting it here[^]
|
|
|
|
|
WPF is quite different from winforms, more resembling a sort of web page than a form from a developing point of view (XAML).
That said, if you want to learn WPF, start with a book and a simple form, if you dive in because you need to animate things or do complex stuff it might blow up in your face.
IOW if you want to dive in WPF, this is not a bad project to do so, but winforms will work equally well in this case.
|
|
|
|
|
In your case, if it isn't critical (or this is for your employer and they're unahppy about supporting a different bit'o'the'framework) I'd go for WPF, just out of interest. I managed to architect a pretty large banking app that had about 10 lines of code runing behine the UI, most of which was exception handling stuff. If you do use WPF, see how it is used with MVVM.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
