Re: Multicast Socket for Win CE 4.2 / Pocket PC 2003



That's at a different level than SOAP. The WinSock code hasn't changed its
API and multicast works, in general, on a variety of devices that I've built
with various OS versions. I can't speak directly for Pocket PC, but I'd be
surprised if it didn't work in a way that's similar to the desktop. It's
never going to *be* the desktop, so don't expect every single thing that you
can do to have the same set of options. Use the basic WinSock calls, not
the WSAxyz calls, for maximum compatibility.

The Unicode thing has *nothing* to do with incompatibility and Microsoft
makes no guarantee that any given piece of code will compile and work
correctly when just copied from the desktop. You have to understand the
issues and take suitable steps. You're passing an incompatible parameter is
all. Unless you are absolutely sure that you understand why a warning is
generated, assume that it's a critical problem with your code, and, as I
said, anything that mentions conversions from char* to unsigned short*
conversions should trigger your Unicode response.

Paul T.

"bpriya" <bpriya@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:30959CEE-7960-4670-81BD-9C2F893F8BF5@xxxxxxxxxxxxxxxx
Thanks for your response. Back to my question, before I start porting, I
want
to make sure that the code which is derived from CAsyncSocket is running
on
WIndows CE. I had experience in the past when porting codes for SOAP
interface
running on desktop, based on the eVC++ manual it also supports that. But
then
it does not even compile. I asked Microsoft people, and they said it's not
supported
anymore on WIn CE, and they will update the manual to avoid confusions for
the
users. So I switch to PocketSOAP which is running now on my target. I hope
the
code for Multicast Socket running on desktop is still supported on Win CE
4.2 Pocket
PC 2003 which is my target now. I'm actually low-level/hardware guy, but I
also got
the S/W porting job from Java simulator to Pocket PC which is brand new
for
me.

Rgds,
bpriya
--



"Paul G. Tobey [eMVP]" wrote:

Whenever you see "cannot convert unsigned short * to char *", you should
automatically think to yourself "Unicode" (or yell it out, if your
coworkers
don't mind). In this case, the method you are calling does *not* expect
a
Unicode (two-byte per character), string, but that's what you are trying
to
pass it. It wants an ordinary ANSI (one-byte per character), string.

On the desktop, you typically are *not* compiling for Unicode; on Windows
CE, you *always* are.

Paul T.

"bpriya" <bpriya@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A83146E8-5762-42E5-8CB7-B42C5A0284BF@xxxxxxxxxxxxxxxx
Thanks for the response. Actually is a simple compile error, eVC++
compiler
does
not take strGroupIP as a string, and the error: cannot convert
parameter 1
from 'const unsigned short *' to 'const char *. I have eVC++ 4.0
compiler.
I
don't
know why the compiler treats 'LPCTSTR strGroupIP' as 'const unsigned
short
*'.

One important point I want to make is that if the codes which run ok on
desktop
can also be ported for Win CE 4.2 environment. I have past experience
that
the
MFC codes that run on desktop don't necessarily work on WinCE MFC
environment.

Rgds,
-bpriya

BOOL CMulticastSocket::CreateReceivingSocket(LPCTSTR strGroupIP, UINT
nGroupPort)
{
/* Create socket for receiving packets from multicast group */
if(!Create(nGroupPort, SOCK_DGRAM, FD_READ))
return FALSE;
BOOL bMultipleApps = TRUE;
SetSockOpt(SO_REUSEADDR, (void*)&bMultipleApps, sizeof(BOOL),
SOL_SOCKET);

/* Fill m_saHostGroup_in for sending datagrams */
memset(&m_saHostGroup, 0, sizeof(m_saHostGroup));
m_saHostGroup.sin_family = AF_INET;
m_saHostGroup.sin_addr.s_addr = inet_addr(strGroupIP);
m_saHostGroup.sin_port = htons((USHORT)nGroupPort);

/* Join the multicast group */
m_mrMReq.imr_multiaddr.s_addr = inet_addr(strGroupIP); /* group addr */
m_mrMReq.imr_interface.s_addr = htons(INADDR_ANY); /* use default */
if(setsockopt(m_hSocket, IPPROTO_IP, IP_ADD_MEMBERSHIP, (char FAR
*)&m_mrMReq, sizeof(m_mrMReq)) < 0)
return FALSE;

return TRUE;
}

"voidcoder" wrote:

The description of your problem is quite vague. What
errors do you get?


"bpriya" <bpriya@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:575FF536-C99F-47E2-8A45-1569202F871C@xxxxxxxxxxxxxxxx
Hi All,

We're developing applications using Embedded VC++ 4.0 on Win CE 4.2
platform
with target of Pocket PC 2003. I'm trying to develop multicast
socket
datagram
using CAsyncSocket as the base class. I downloaded sample code from
web
site
using CAsyncSocket which runs well on desktop PC. Does anybody know
that this
should work also on Win CE 4.2 ? I tried to port this code to my
application
on Win
CE 4.2 but it does not even compile correctly. Maybe I should make
some
changes
but I don't want to waste time if it is not going to work later on.
Appreciate any
inputs.

Thanks for your kind responses.
-priyanto.


--









.



Relevant Pages

  • Re: How to display German Umlauts correctly on Mac and Unix
    ... > larger due to translation tables). ... If you have to custom compile build tools to get a feature, ... And with the Unicode translation steps. ... "are written using the Unicode character set". ...
    (comp.lang.java.gui)
  • Re: Difference between String variable and String Class definition
    ... both compile to the bytecode of the first statement? ... the pennies from my pocket, because my pocket is not yours. ...
    (comp.lang.java.programmer)
  • Re: Re[2]: Pre-information on Unicode in Delphi 2008
    ... and will not compile if the new VCL is utterly Unicode. ... So "all existing" applications would break and simply making application ... This is NOT what string encoding RTTI would be for, ...
    (borland.public.delphi.non-technical)
  • Re: "Not a valid pocket pc application" -- not just trying to install an exe on the pocke
    ... When I compile using the ARVV4 option i get the following ... run it from the pocket pc. ... I read that that means i should use x86 selection because ... option does link where the ARM selection fails. ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: String Manipulations
    ... >> Unicode although after taking your advice it worked as I originally ... >> within the same scope of the CString example that wont compile either. ... >> Perhaps my project environment needs to be adjusted a bit? ... >> sample code shouldn't be this cumbersome. ...
    (microsoft.public.vc.language)