Sign in with
Sign up | Sign in
Your question

Recommendation of Development Tools for Wireless and Barco..

Last response: in Cell Phones & Smartphones
Share
Anonymous
a b F Wireless
November 23, 2004 11:20:47 AM

Archived from groups: microsoft.public.pocketpc (More info?)

I would like to develop a relatively simple application on a Symbol
PPT 2846 barcode scanner (I believe it is based on Pocket PC). I would
like to know which development tools that I should use.

My application needs to do:
- Scan a barcode number and send it to our database (via a SQL Server
stored procedure) in a centralized database server.
- We need to do this in wireless and need to do this immediately right
after scanning (this means not in a batch mode).
- There will be a few other screens for data retrieval.

Should I use the following tools:
- MS eMbedded Visual Tools 3.0 (it also has MS Pocket PC SDK)
- MS ActiveSync 3.7.1
- Symbol PPT 2800 Windows CE SDK v1.01 or
Symbol PPT 2800_2002 Windows CE SDK v2.00

Are these enough for developing the application?
Do the Symbol SDKs handle barcode scanning and wireless connection?
Are there other development tools that are more appropriate?

BTW, I have a lot of experience in C/C++, WinAPI/MFC, VB/MsAccess, and
CGI. But I don't know much about ASP or .NET.

I have checked Symbol forum. But that forum is not quite active.
Therefore, I post this message here.

Thanks in advance for any recommendation.

Jay Chan
Anonymous
a b F Wireless
November 23, 2004 1:02:20 PM

Archived from groups: microsoft.public.pocketpc (More info?)

Hi,

The tools that you list probably are enough (I've done similar in the past;
in that app I used Winsock to connect to a server application (sent it the
scanned data) that did all of the heavy lifting -- SQL interface, serving up
web pages VB and ASP, etc.).

However, eMbedded Tools 3.0 and eVB are deprecated. That means that
Microsoft does not support the tool, and they will not work "down the road"
on later versions of PPC and Windows CE. For that reason, I'd suggest that
you consider Visual Studio 2003 Pro (or higher), which allows you to use the
Compact Framework, and supports either VB or C# languages.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.
Anonymous
a b F Wireless
November 23, 2004 8:03:53 PM

Archived from groups: microsoft.public.pocketpc (More info?)

On 23 Nov 2004 08:20:47 -0800, jaykchan@hotmail.com (Jay Chan) wrote:

>I would like to develop a relatively simple application on a Symbol
>PPT 2846 barcode scanner (I believe it is based on Pocket PC). I would
>like to know which development tools that I should use.

The following gives specs for the PPT 2800 series:
http://www.symbol.com/products/mobile_computers/mobile_...
A table called "Performance Characteristics" says it is based on
Pocket PC 2002. I _assume_ the 2846 is part of this series. For more
about "platforms", see
http://www.opennetcf.org/Forums/topic.asp?TOPIC_ID=317
Pocket PC 2002 supports .NET CF (Compact Format), but does not include
it. That means the installer for any app using CF must make sure CF is
loaded.

>
>My application needs to do:
>- Scan a barcode number and send it to our database (via a SQL Server
> stored procedure) in a centralized database server.
>- We need to do this in wireless and need to do this immediately right
> after scanning (this means not in a batch mode).

Sigh. Our app proudly works in batch mode. I say proudly because it
means our app works even when no connection is available. So I urge
you to reconsider, even if you don't choose to buy our app.


>- There will be a few other screens for data retrieval.

The biggest challenge for programmers is changing specs. Especially if
the folks who do the programming are far removed from the folks who
use the program. They can be major time and money sinks.


>
>Should I use the following tools:
>- MS eMbedded Visual Tools 3.0 (it also has MS Pocket PC SDK)
>- MS ActiveSync 3.7.1
>- Symbol PPT 2800 Windows CE SDK v1.01 or
> Symbol PPT 2800_2002 Windows CE SDK v2.00
>
>Are these enough for developing the application?
>Do the Symbol SDKs handle barcode scanning and wireless connection?

The main point of the Symbol SDKs is to handle the barcode scanners.
Supporting barcode scanners is a big part of my application. I
generally avoid SDKs, because I don't want to deal with multiple,
specialized, versions of my app. So I almost always recommend using a
"keyboard wedge"; for more info, use google
(http://groups.google.com/advanced_group_search) to look up
wedge
in contributions from me. On the other hand, using the SDK will let
you create a more reliable connection. So, if you really are going to
use only Symbol hardware, than using their SDK(s) makes sense.


>Are there other development tools that are more appropriate?

I'm clearly biased, but I really think buying an application is often
less expensive than developing and debugging one. Our app basically
uses a script, so _customers_ can change screens rather easily.


>
>BTW, I have a lot of experience in C/C++, WinAPI/MFC, VB/MsAccess, and
>CGI. But I don't know much about ASP or .NET.

This info favors eVC. If you wanted to use .NET to support Windows
CE/Pocket PC, you would need to get Visual Studio .NET Professional
and use VB or C#.


>
>I have checked Symbol forum. But that forum is not quite active.
>Therefore, I post this message here.

Try microsoft.public.pocketpc.developer. In particular, try using
google to look up
newbie
in that newsgroup. You will find a lot of notes from me urging folks
to use google. But you will also find a lot of real info.


>
>Thanks in advance for any recommendation.
>
>Jay Chan

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com
Related resources
Anonymous
a b F Wireless
November 23, 2004 8:03:53 PM

Archived from groups: microsoft.public.pocketpc (More info?)

On Tue, 23 Nov 2004 10:02:20 -0700, "Dick Grier"
<dick_grierNOSPAM@msn.com> wrote:

>Hi,
>
>The tools that you list probably are enough (I've done similar in the past;
>in that app I used Winsock to connect to a server application (sent it the
>scanned data) that did all of the heavy lifting -- SQL interface, serving up
>web pages VB and ASP, etc.).
>
>However, eMbedded Tools 3.0 and eVB are deprecated. That means that
>Microsoft does not support the tool, and they will not work "down the road"
>on later versions of PPC and Windows CE. For that reason, I'd suggest that
>you consider Visual Studio 2003 Pro (or higher), which allows you to use the
>Compact Framework, and supports either VB or C# languages.

Support for eVB has definitely stopped. But eVC is a different story.
Microsoft may be largely ignoring it, but I am quite sure it is not
going away in the foreseeable future. I can't come up with reference,
but I'm quite sure I've seen such assurances from "reliable" sources
recently.

>
>Dick

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com
Anonymous
a b F Wireless
November 24, 2004 9:30:31 AM

Archived from groups: microsoft.public.pocketpc (More info?)

> The tools that you list probably are enough (I've done similar in the past;
> in that app I used Winsock to connect to a server application (sent it the
> scanned data) that did all of the heavy lifting -- SQL interface, serving up
> web pages VB and ASP, etc.).

Thanks for sharing your experience. I assume that your app is working
like a telnet session. This means your app doesn't need to worry about
connecting to the database; the server-part of the program handles the
database connection. Actually, this is exactly how our existing
DOS-based barcode scanning program works.

> However, eMbedded Tools 3.0 and eVB are deprecated. That means that
> Microsoft does not support the tool, and they will not work "down the road"
> on later versions of PPC and Windows CE. For that reason, I'd suggest that
> you consider Visual Studio 2003 Pro (or higher), which allows you to use the
> Compact Framework, and supports either VB or C# languages.

Oh well... This means I am better off not to go down that road. I
think I will have to start looking for MS Visual Studio 2003. I was
told elsewhere that I should use the database connectivity class in
..NET for database connection. This means I probably need to also look
at .NET (some of the main applications in our company are written in
..NET anyway).

Thanks again for sharing your experience.

Jay Chan
Anonymous
a b F Wireless
November 24, 2004 9:39:15 AM

Archived from groups: microsoft.public.pocketpc (More info?)

> The tools that you list probably are enough (I've done similar in the past;
> in that app I used Winsock to connect to a server application (sent it the
> scanned data) that did all of the heavy lifting -- SQL interface, serving up
> web pages VB and ASP, etc.).

I forgot to mention that our existing terminal-session type of program
has one shortcoming:
- Because of the use of 802.11b and there is a large metal structure
and metal gate between the access points and the barcode scanner, the
connection is not reliable. For some reason, when the barcode scanner
loses the connection, we must restart the server-part of the program
in order to get the barcode scanner to properly connected. Does this
have to do with the use of terminal-session? Does terminal-session
require a very good connection? If this is the case, we will have to
stay away from this approach and use a different approach that may be
more forgiving.

Jay Chan
Anonymous
a b F Wireless
November 24, 2004 10:26:17 AM

Archived from groups: microsoft.public.pocketpc (More info?)

> The following gives specs for the PPT 2800 series:
> http://www.symbol.com/products/mobile_computers/mobile_...
> A table called "Performance Characteristics" says it is based on
> Pocket PC 2002. I _assume_ the 2846 is part of this series.

Yes, PPT-2846 is a part of the 2800-serie. PPT-2846 comes with
wireless RF capability that a basic PPT-2800 (batch) doesn't have.

> Pocket PC 2002 supports .NET CF (Compact Format), but does not include
> it. That means the installer for any app using CF must make sure CF is
> loaded.

I am not aware that I need to use .NET Compact Framework. Strangely,
the software requirement for "Symbol Mobility Developer Kit for .NET"
(SMDK) doesn't mention .NET CF either. Would you please tell me why I
need it. Thanks.

> Sigh. Our app proudly works in batch mode. I say proudly because it
> means our app works even when no connection is available. So I urge
> you to reconsider, even if you don't choose to buy our app.

Yes, I understand the benefit of working in batch mode. But going
wireless is the project requirement. Actually, the existing barcode
scanning system is already wireless. Therefore, I don't want to
re-train the workers. I intend to add the batch mode in a later day as
a backup in case the system is down or the wireless connection is not
good.

> The biggest challenge for programmers is changing specs. Especially if
> the folks who do the programming are far removed from the folks who
> use the program. They can be major time and money sinks.

Not a problem in this case. We have already had a barcode scanning
system up and running. Therefore, the spec cannot be more final than
this. We need to replace the system because it is a DOS based system
and the manufacturers have discontinused their DOS-based barcode
scanners.

> The main point of the Symbol SDKs is to handle the barcode scanners.
> Supporting barcode scanners is a big part of my application. I
> generally avoid SDKs, because I don't want to deal with multiple,
> specialized, versions of my app. So I almost always recommend using a
> "keyboard wedge"; for more info, use google
> (http://groups.google.com/advanced_group_search) to look up
> wedge
> in contributions from me. On the other hand, using the SDK will let
> you create a more reliable connection. So, if you really are going to
> use only Symbol hardware, than using their SDK(s) makes sense.

If I understand the concept of your "keyboard wedge" correctly, it is
a way to capture the scanned barcode number, and feed it to the
application via the keyboard queue. Therefore, it is like one of those
useful TSR (terminated-stay-resident) that we like to use in DOS-era.
I used to write a TSR like that to feed the mouse location and mouse
click to a DOS program via the keyboard queue. That was pre-Windows
era. Actually, I was not proud of writing that program for reasons
that I don't want to get into here. Anyway, my experience tells me
that I should stick with using a SDK if it is available or get a third
party library that provides the API and does the heavy lifting for me.

> I'm clearly biased, but I really think buying an application is often
> less expensive than developing and debugging one. Our app basically
> uses a script, so _customers_ can change screens rather easily.

In general, I would agree with you. But we have gone through this once
before with the existing barcode scanning system. This was OK when we
asked the developer to develop a new system. But when we need to add a
feature or when we need to port the system to a different platform, we
will be charged a _large_ sum. On top of this, we don't have the
source code of the "real" program (only the scripts), and there is
copy-protection scheme that complicates our system installation, and
is costly just to move the program from one server to another server.
This means we have been burnt once. This time, we will do thing
differently. We will use standard SDK, fully documented source code of
anything outside the standard SDK, no copy protection scheme to
confuse our setup.

> This info favors eVC. If you wanted to use .NET to support Windows
> CE/Pocket PC, you would need to get Visual Studio .NET Professional
> and use VB or C#.

Thanks for the advice. I have access to Visual Studio .NET through
MSDN. I probably will use VB instead of C# to help the programmer who
may need to take over the system when I am gone.

> Try microsoft.public.pocketpc.developer.

Thanks for the link. I will check it out.

Jay Chan
Anonymous
a b F Wireless
November 24, 2004 10:36:30 AM

Archived from groups: microsoft.public.pocketpc (More info?)

> The following gives specs for the PPT 2800 series:
> http://www.symbol.com/products/mobile_computers/mobile_...
> A table called "Performance Characteristics" says it is based on
> Pocket PC 2002. I _assume_ the 2846 is part of this series.

Yes, PPT-2846 is a part of the 2800-serie. PPT-2846 comes with
wireless RF capability that a basic PPT-2800 (batch) doesn't have.

> Pocket PC 2002 supports .NET CF (Compact Format), but does not include
> it. That means the installer for any app using CF must make sure CF is
> loaded.

I am not aware that I need to use .NET Compact Framework. Strangely,
the software requirement for "Symbol Mobility Developer Kit for .NET"
(SMDK) doesn't mention .NET CF either. Would you please tell me why I
need it. Thanks.

> Sigh. Our app proudly works in batch mode. I say proudly because it
> means our app works even when no connection is available. So I urge
> you to reconsider, even if you don't choose to buy our app.

Yes, I understand the benefit of working in batch mode. But going
wireless is the project requirement. Actually, the existing barcode
scanning system is already wireless. Therefore, I don't want to
re-train the workers. I intend to add the batch mode in a later day as
a backup in case the system is down or the wireless connection is not
good.

> The biggest challenge for programmers is changing specs. Especially if
> the folks who do the programming are far removed from the folks who
> use the program. They can be major time and money sinks.

Not a problem in this case. We have already had a barcode scanning
system up and running. Therefore, the spec cannot be more final than
this. We need to replace the system because it is a DOS based system
and the manufacturers have discontinused their DOS-based barcode
scanners.

> The main point of the Symbol SDKs is to handle the barcode scanners.
> Supporting barcode scanners is a big part of my application. I
> generally avoid SDKs, because I don't want to deal with multiple,
> specialized, versions of my app. So I almost always recommend using a
> "keyboard wedge"; for more info, use google
> (http://groups.google.com/advanced_group_search) to look up
> wedge
> in contributions from me. On the other hand, using the SDK will let
> you create a more reliable connection. So, if you really are going to
> use only Symbol hardware, than using their SDK(s) makes sense.

If I understand the concept of your "keyboard wedge" correctly, it is
a way to capture the scanned barcode number, and feed it to the
application via the keyboard queue. Therefore, it is like one of those
useful TSR (terminated-stay-resident) that we like to use in DOS-era.
I used to write a TSR like that to feed the mouse location and mouse
click to a DOS program via the keyboard queue. That was pre-Windows
era. Actually, I was not proud of writing that program for reasons
that I don't want to get into here. Anyway, my experience tells me
that I should stick with using a SDK if it is available or get a third
party library that provides the API and does the heavy lifting for me.

> I'm clearly biased, but I really think buying an application is often
> less expensive than developing and debugging one. Our app basically
> uses a script, so _customers_ can change screens rather easily.

In general, I would agree with you. But we have gone through this once
before with the existing barcode scanning system. This was OK when we
asked the developer to develop a new system. But when we need to add a
feature or when we need to port the system to a different platform, we
will be charged a _large_ sum. On top of this, we don't have the
source code of the "real" program (only the scripts), and there is
copy-protection scheme that complicates our system installation, and
is costly just to move the program from one server to another server.
This means we have been burnt once. This time, we will do thing
differently. We will use standard SDK, fully documented source code of
anything outside the standard SDK, no copy protection scheme to
confuse our setup.

> This info favors eVC. If you wanted to use .NET to support Windows
> CE/Pocket PC, you would need to get Visual Studio .NET Professional
> and use VB or C#.

Thanks for the advice. I have access to Visual Studio .NET through
MSDN. I probably will use VB instead of C# to help the programmer who
may need to take over the system when I am gone.

> Try microsoft.public.pocketpc.developer.

Thanks for the link. I will check it out.

Jay Chan
Anonymous
a b F Wireless
November 24, 2004 3:26:42 PM

Archived from groups: microsoft.public.pocketpc (More info?)

Hi,

Support for eMbedded Tools 3.0 has ended (even eVC). However, eMbedded
Tools 4.0 support continues. That is where you find eVC for current
development.

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.
Anonymous
a b F Wireless
November 24, 2004 3:33:42 PM

Archived from groups: microsoft.public.pocketpc (More info?)

Hi,

>>
Thanks for sharing your experience. I assume that your app is working
like a telnet session. This means your app doesn't need to worry about
connecting to the database; the server-part of the program handles the
database connection. Actually, this is exactly how our existing
DOS-based barcode scanning program works.
<<

Yes. I don't use Telnet, but a simple protocol that I developed. But, in
effect the result is the same.

>>
Oh well... This means I am better off not to go down that road. I
think I will have to start looking for MS Visual Studio 2003. I was
told elsewhere that I should use the database connectivity class in
..NET for database connection. This means I probably need to also look
at .NET (some of the main applications in our company are written in
..NET anyway).
<<

You can use SQL CE for connectivity to a SQL Server. This may well be the
best solution.

Dick

--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 4th
Edition ISBN 1-890422-28-2 (391 pages) published July 2004. See
www.mabry.com/vbpgser4 to order.
Anonymous
a b F Wireless
November 24, 2004 7:17:03 PM

Archived from groups: microsoft.public.pocketpc (More info?)

On 24 Nov 2004 07:26:17 -0800, jaykchan@hotmail.com (Jay Chan) wrote:

>> The following gives specs for the PPT 2800 series:
>> http://www.symbol.com/products/mobile_computers/mobile_...
>> A table called "Performance Characteristics" says it is based on
>> Pocket PC 2002. I _assume_ the 2846 is part of this series.
>
>Yes, PPT-2846 is a part of the 2800-serie. PPT-2846 comes with
>wireless RF capability that a basic PPT-2800 (batch) doesn't have.
>
>> Pocket PC 2002 supports .NET CF (Compact Format), but does not include
>> it. That means the installer for any app using CF must make sure CF is
>> loaded.
>
>I am not aware that I need to use .NET Compact Framework. Strangely,
>the software requirement for "Symbol Mobility Developer Kit for .NET"
>(SMDK) doesn't mention .NET CF either. Would you please tell me why I
>need it. Thanks.

I don't use .NET, so I'm not a great source of info. But I'm pretty
sure CF provides the run-time support for .NET on mobile devices.


>
>> Sigh. Our app proudly works in batch mode. I say proudly because it
>> means our app works even when no connection is available. So I urge
>> you to reconsider, even if you don't choose to buy our app.
>
>Yes, I understand the benefit of working in batch mode. But going
>wireless is the project requirement. Actually, the existing barcode
>scanning system is already wireless. Therefore, I don't want to
>re-train the workers. I intend to add the batch mode in a later day as
>a backup in case the system is down or the wireless connection is not
>good.

I think some clarification/fussiness is important here. Specifically,
wireless is not the opposite of batch. "Wireless" describes a way of
connecting whenever a device _is_ connected. "Batch" means the device
can be used even when not connected.

>
>> The biggest challenge for programmers is changing specs. Especially if
>> the folks who do the programming are far removed from the folks who
>> use the program. They can be major time and money sinks.
>
>Not a problem in this case. We have already had a barcode scanning
>system up and running. Therefore, the spec cannot be more final than
>this. We need to replace the system because it is a DOS based system
>and the manufacturers have discontinused their DOS-based barcode
>scanners.
>
>> The main point of the Symbol SDKs is to handle the barcode scanners.
>> Supporting barcode scanners is a big part of my application. I
>> generally avoid SDKs, because I don't want to deal with multiple,
>> specialized, versions of my app. So I almost always recommend using a
>> "keyboard wedge"; for more info, use google
>> (http://groups.google.com/advanced_group_search) to look up
>> wedge
>> in contributions from me. On the other hand, using the SDK will let
>> you create a more reliable connection. So, if you really are going to
>> use only Symbol hardware, than using their SDK(s) makes sense.
>
>If I understand the concept of your "keyboard wedge" correctly, it is
>a way to capture the scanned barcode number, and feed it to the
>application via the keyboard queue. Therefore, it is like one of those
>useful TSR (terminated-stay-resident) that we like to use in DOS-era.
>I used to write a TSR like that to feed the mouse location and mouse
>click to a DOS program via the keyboard queue. That was pre-Windows
>era. Actually, I was not proud of writing that program for reasons
>that I don't want to get into here. Anyway, my experience tells me
>that I should stick with using a SDK if it is available or get a third
>party library that provides the API and does the heavy lifting for me.

You got the idea. My usual advice is to use the wedge that comes with
the scanner, and to avoid any scanner that doesn't come with a wedge.
Such wedges _are_ kludges, and I worry that my users depend on them.
But our experience shows that they work far better than I fear.

>
>> I'm clearly biased, but I really think buying an application is often
>> less expensive than developing and debugging one. Our app basically
>> uses a script, so _customers_ can change screens rather easily.
>
>In general, I would agree with you. But we have gone through this once
>before with the existing barcode scanning system. This was OK when we
>asked the developer to develop a new system. But when we need to add a
>feature or when we need to port the system to a different platform, we
>will be charged a _large_ sum. On top of this, we don't have the
>source code of the "real" program (only the scripts), and there is
>copy-protection scheme that complicates our system installation, and
>is costly just to move the program from one server to another server.
>This means we have been burnt once. This time, we will do thing
>differently. We will use standard SDK, fully documented source code of
>anything outside the standard SDK, no copy protection scheme to
>confuse our setup.

We aren't nearly so draconian. And we support just about anything
running any version of Windows. But I understand your concerns.

One rarely mentioned, but somewhat relevant feature of .NET
applications is that the compiler actually generates a pseudo-code
intermediate, which is what is distributed. The target may use an
interpreter of just-in-time compiler. Either way, the pseudo-code is
actually human-readable. Not good for folks who want to keep their
code private. Maybe good for you. (Yes, I know obfuscators exist, but
I also know de-obfuscators exist.)

>
>> This info favors eVC. If you wanted to use .NET to support Windows
>> CE/Pocket PC, you would need to get Visual Studio .NET Professional
>> and use VB or C#.
>
>Thanks for the advice. I have access to Visual Studio .NET through
>MSDN. I probably will use VB instead of C# to help the programmer who
>may need to take over the system when I am gone.
>
>> Try microsoft.public.pocketpc.developer.
>
>Thanks for the link. I will check it out.
>
>Jay Chan

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com
Anonymous
a b F Wireless
November 24, 2004 7:17:07 PM

Archived from groups: microsoft.public.pocketpc (More info?)

On Wed, 24 Nov 2004 12:26:42 -0700, "Dick Grier"
<dick_grierNOSPAM@msn.com> wrote:

>Hi,
>
>Support for eMbedded Tools 3.0 has ended (even eVC). However, eMbedded
>Tools 4.0 support continues. That is where you find eVC for current
>development.

Sure enough, that's what you said earlier (I just checked). Sometimes
I don't read so well. Thanks for the gentle clarification.

-----------------------------------------
To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

Robert E. Zaret, eMVP
PenFact, Inc.
500 Harrison Ave., Suite 3R
Boston, MA 02118
www.penfact.com
May 27, 2014 12:43:12 AM

Anonymous said:
Archived from groups: microsoft.public.pocketpc (More info?)

I would like to develop a relatively simple application on a Symbol
PPT 2846 barcode scanner (I believe it is based on Pocket PC). I would
like to know which development tools that I should use.

My application needs to do:
- Scan a barcode number and send it to our database (via a SQL Server
stored procedure) in a centralized database server.
- We need to do this in wireless and need to do this immediately right
after scanning (this means not in a batch mode).
- There will be a few other screens for data retrieval.

Should I use the following tools:
- MS eMbedded Visual Tools 3.0 (it also has MS Pocket PC SDK)
- MS ActiveSync 3.7.1
- Symbol PPT 2800 Windows CE SDK v1.01 or
Symbol PPT 2800_2002 Windows CE SDK v2.00

Are these enough for developing the application?
Do the Symbol SDKs handle barcode scanning and wireless connection?
Are there other development tools that are more appropriate?

BTW, I have a lot of experience in C/C++, WinAPI/MFC, VB/MsAccess, and
CGI. But I don't know much about ASP or .NET.

I have checked Symbol forum. But that forum is not quite active.
Therefore, I post this message here.

Thanks in advance for any recommendation.

Jay Chan


Well, you can try to switch to another barcode reader tool that can be easy to use.
!