|
Honeyboy_20 wrote: I have problem when I am try to send byte to serial port.
for example
int x=153;
when i get the hexa decimal of 153 it's 99
but when I am try to send it , it appear as 3F but I want it to be 99 as hexa decimal
There is more text than information here. It needs dissecting.
Honeyboy_20 wrote: I have problem when I am try to send byte to serial port.
that is not a question. And neither is the rest of your message. So I will ask some questions you can think about.
Honeyboy_20 wrote: int x=153;
why would you need an int if you want to send a byte. How about declaring a byte instead?
Honeyboy_20 wrote: when i get the hexa decimal of 153 it's 99
why would you need hex at all? how is that relevant? you can send bytes through a serial port, no matter what values they contain or whatever they represent.
Honeyboy_20 wrote: but when I am try to send it , it appear as 3F
that is a bit of a surprise. there must be some magical code involved here. I have a rough idea how one could do it, but hey, I trust your code is much better than that.
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.
|
|
|
|
|
An excellent analysis; have a 5.
I must get a clever new signature for 2011.
|
|
|
|
|
Thank you kindly sir.
I can hardly wait for the next episode.
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.
|
|
|
|
|
I do agree with Luc Pattyn in that sending 153 or 0x99 doesn't make any difference. It's just a matter of output formatting.
Maybe there is some decimal-to-hex formatting code in your program, which I believe you don't need at all.
The reason for me to suspect that are the following equations:
153 = 0x99
99 = 0x63
63 = 0x3F So there is a connection between the numerical values you mentioned.
Ciao,
luker
|
|
|
|
|
Is that a problem with signed versus unsigned bytes? 153 is bigger than the maximum value of a signed byte, while 99 is small enough to fit into a signed byte.
But there are no signed bytes in .NET... How do you convert from int to byte?
|
|
|
|
|
Bernhard Hiller wrote: But there are no signed bytes in .NET...
And what do you think System.SByte is for ? :p
|
|
|
|
|
int num = 153;
string hex = num.ToString("X2");
byte send = byte.Parse(hex , System.Globalization.NumberStyles.AllowHexSpecifier);
|
|
|
|
|
I am building an application that is supposed to eventually print out a receipt. Someone told me that i can get an E-POS receipt printer. Is it possible to interface it with a computer, that is, is there any DLL that i can use to send the printing jobs to an E-POS printer. I am programing using C Sharp (Of course).
Wamuti: Any man can be an island, but islands to need water around them!
Edmund Burke: No one could make a greater mistake than he who did nothing because he could do only a little.
|
|
|
|
|
If the printer comes with Windows printer driver, you basically just have to set the page size and print to the document.
Older printers let you print to them like STDOUT so you'd just issue WriteLines which is easy enough to do.
Some printers accept a raw data format for printing, in which case you can check out this Microsoft KB[^].
Also, check with the EPOS supplier and see if they have an SDK. You may be best to research a couple of leading ones or a standard format and then give you end user a set of choices, failing back to one of the methods above.
Edit: just remembered the Microsoft POS framework[^]. It seemed pretty good when I last looked into it.
Cheers.
|
|
|
|
|
Google [NAME OF PRINTER] and Drivers, DLL or SDK.
That should be enough to find the answer to your problem.
------------------------------------
I will never again mention that I was the poster of the One Millionth Lounge Post, nor that it was complete drivel. Dalek Dave
CCC Link[ ^]
Trolls[ ^]
|
|
|
|
|
I'm not sure about "E-POS", is that something based on the Unified POS standard? UPOS is an architecture for communicating with retail point of sale devices. The manufacturer of a UPOS-enabled receipt printer supplies a "service object" dll. Your code would use "POS for .NET" to talk to the receipt printer.
See:
Microsoft POS for .NET Overview[^]
National Retail Federation, Unified POS[^]
|
|
|
|
|
Hi Guys,
I have a DLL created in Visual Studio 6 / C++ with the following function
MyDLL_API int __stdcall MyMethod( char *strA, char *strB, char *strC )
i am trying to reference it like so in c# 2005
[DllImport("mydll.dll", CharSet = CharSet.Auto)]
public static extern int MyMethod(ref string strA, ref string strB, ref string strC);
Here is the debugging code i added to MyMethod but the params are garbage when presented on screen:
MyDLL_API int __stdcall MyMethod( char *strA, char *strB, char *strC )
int ret_val = 0;
char cA[161] = {0};
char cB[161] = {0};
char cC[161] = {0};
LPSTR buffer = NULL;
char cMsg[161] = {0};
buffer = (LPSTR)strA;
strncpy( cA, buffer, 161);
buffer = (LPSTR)strB;
strncpy( cB, buffer, 161);
buffer = (LPSTR)strC;
strncpy( cC, buffer, 161);
sprintf( cMsg, "Params A=%s,B=%s,C=%s", strA, strB, strC );
MessageBox( NULL, cMsg, "Dispense", MB_OK );
the function gets called but all i see is garbage in the parameters passed in, other than a string what else can i use to pass to the Char*?
Thanks In Advance
modified on Tuesday, March 22, 2011 10:29 AM
|
|
|
|
|
The default marshalling type for C# strings is Unicode (2 bytes per character) as described here[^]. You will need to modify your C++ code to handle Unicode characters, or add a front end converter from WCHAR to CHAR.
I must get a clever new signature for 2011.
|
|
|
|
|
Thanks Richard,
I cant modify the dll as its from a third party and they just sent me on a samepl of the code they use how would I go about adding a front end converter from WCHAR to CHAR?
Thanks In Advance
|
|
|
|
|
Just write your own C/C++ function that interfaces to the C# code and takes the three strings and converts them from Unicode to char using the WideCharToMultiByte()[^] function. You can then pass the converted strings to the DLL routines.
I must get a clever new signature for 2011.
|
|
|
|
|
Just an update on this, I found that if i do the following in C#
[DllImport("mydll.dll", CharSet = CharSet.Auto)]
public static extern int MyMethod(
[param: MarshalAs(UnmanagedType.VBByRefStr)]
ref string strA,
[param: MarshalAs(UnmanagedType.VBByRefStr)]
ref string strB,
[param: MarshalAs(UnmanagedType.VBByRefStr)]
ref string strC);
That my messagebox in MyMethod in the dll shows the first character of the strings eg passing 1, 234, 5 the results are A=1,B=2,C=5
|
|
|
|
|
That sounds about right as the Unicode characters for these values are the same as ANSI. However, because the Unicode are 2-byte characters, and the second byte in these cases will be zero, you effectively see a 1 character string in each parameter.
I must get a clever new signature for 2011.
|
|
|
|
|
Hi Richard,
Thanks for all the help.
After playing around with a few other things i found that this works
[DllImport("MyDll.dll", CharSet = CharSet.Unicode)]
public static extern int MyMethod(
[param: MarshalAs(UnmanagedType.LPStr)]
StringBuilder strA,
[param: MarshalAs(UnmanagedType.LPStr)]
StringBuilder strB,
[param: MarshalAs(UnmanagedType.LPStr)]
StringBuilder strC);
changeg need were to remove the ref keyword, changes string to stringbuilder and the unmanaged type to LPStr
|
|
|
|
|
Great stuff. I see that you also got some help from Ian, and Luc who knows far more about this than I do.
I must get a clever new signature for 2011.
|
|
|
|
|
I'm no expert on C++ interfacing, so I'd defer to Richard on this, but I think marshaling as UnmanagedType.LPStr might take care of this.
According to the MSDN docs, that'd send them through as single-byte, null-terminated strings. Would eliminate the need to convert from Unicode.
EDIT: Never mind, looks like you already figured this out 
|
|
|
|
|
Some of the replies you got contain too much attributes IMO. Passing strings between C# and native code is pretty easy, you don't even need all those Marshal thingies, a simple CharSet = CharSet.Unicode
[ADDED] or CharSet = CharSet.ASCII [ADDED]
in your DllImport should do it. You must get rid of the ref keywords obviously, as a string is always passed as a pointer anyway. And if one or more of those strings are meant to be output parameters, the easiest way is by using a StringBuilder. I think I covered all these essentials in this article[^].
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. modified on Tuesday, March 22, 2011 12:32 PM
|
|
|
|
|
Hi Luc,
I tried what you said as well but I only get see the first character in the C++ method, here is the code:
[DllImport("MyDll.dll", CharSet = CharSet.Unicode)]
public static extern int MyMethod(
string strA,
string strB,
string strC);
I took out the
[param: MarshalAs(UnmanagedType.LPStr)]
but it seems that this is needed
|
|
|
|
|
sorry, my mistake, if your native code wants ASCII, just say CharSet.ASCII. There is automatic marshaling that will allocate and later free buffers, translate the strings and everything for you.
Warning: you are not allowed to remember those string pointers (actually any pointer unless the object remains pinned) and use them after the function return!
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.
|
|
|
|
|
Hi Luc,
Thanks that works perfectly, you learn something new every day 
|
|
|
|
|
I have developed a windows application in visual studio 2008.
This application connects to sql server 2005 Express by using a login in sql server.
As soon as the appplication runs (When the form is loaded), there is connection to the sql server, data is retrieved and displayed on the form.
In the clickonce, I just created the setup. After installtion from the CD onto the client machine, the form appears but obviously because there is no sql server 2005 express installed on the client, then the application fails to load data.
I am trying not to install the sql server 2005 express onto the machine and would like the clickonce to take care of the .mdf file.
Question
Using the clickonce procedure to create a setup onto a CD, is there an option to add the .mdf to the setup too? so that I do not have to install the sql server separately?
Note that I do NOT have .mdf in the solution of VS and the application uses a config file to connect to sql server as a connectionstring.
Thanks
modified on Tuesday, March 22, 2011 9:47 AM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
