Hi all, quick question. I recently purchased several hand held symbol
barcode scanners running Windows Mobile for a client. They were going
to use them for scanning products into a web app in their warehouse.
Initially, their software developer said the only requirement for
these devices was that they had the latest version of IE, which these
do. But now they have ran into a glitch and the story has changed.

The "glitch" is this: when the users scan a barcode into the field and
press enter, it should do what you would expect and submit the
scanning information. But it does not. The user is forced to press the
SUBMIT button that they coded into the page in order to send the data.
The desired function is that the barcode software (datawedge) send an
ENTER after every scan, but their page doesn't recognize it (or
pressing enter on the keypad). You have to physically press the submit
button on the touch screen.

They are blaming this on the fact that the devices have Mobile 2003
and not Windows CE and that there is no way to fix the code to
accommodate this. I am not a developer, so I can't dispute it, despite
the fact that it just doesn't seem logical to me.

Could some kind soul out there please provide some expertise please?
Thanks!

You are in the middle of a finger pointing exercise.

The logical party to solve the problem is the software vendor (assume it
is web based) to provide a code change that accepts the data based on
the action of filling the field... normally that the scanner sends the
collected data followed by a <carriage return>

Another possibility is that they assume the latest version of ie on the
desktop... i.e. full java support, which I would guess is the root of
this issue.

Before you attack that, I would check to confirm that the collector is
indeed doing so... i.e. start a word document, scan a couple of codes
and confirm that they are each ending up on their own line, not one
after another.

If not, see if there is a configuration option on the scanners to set a
carriage return.

Beyond that there are some options, but, imho, the best solution is for
the current parties to work together for a long term solution which will
work on any default wince device.

Beverly Howard [MS MVP-Mobile Devices]

First, I'm a developer who supports bar codes in my applications, and
I rely on keyboard wedges provided by the reader vendors. Second, you
provided a pretty good description, but I definitely don't want to get
between you and the suppliers, so I am going to be cautious. More
below (in line)


On 29 Jan 2007 13:17:47 -0800, chillzatl@gmail.com wrote:

>Hi all, quick question. I recently purchased several hand held symbol
>barcode scanners running Windows Mobile for a client. They were going
>to use them for scanning products into a web app in their warehouse.
>Initially, their software developer said the only requirement for
>these devices was that they had the latest version of IE, which these
>do. But now they have ran into a glitch and the story has changed.
>
>The "glitch" is this: when the users scan a barcode into the field and
>press enter, it should do what you would expect and submit the
>scanning information. But it does not. The user is forced to press the
>SUBMIT button that they coded into the page in order to send the data.
>The desired function is that the barcode software (datawedge) send an
>ENTER after every scan, but their page doesn't recognize it (or
>pressing enter on the keypad). You have to physically press the submit
>button on the touch screen.

Keyboard wedges are elegantly stupid. They send keystrokes to whatever
window has focus. Platform, operating system, language (human and
programming) don't matter to the wedge. However, the window that gets
the keystrokes needs to know how to handle them. In your case, that
means the application. Also, users have to be at least a bit careful
to make sure the correct window has focus (think what might happen if
the start menu got all those keystrokes). This "loophole" worries me,
but in practice, users seem to learn quickly. Of course, some
applications are more challenging than others.

Sure seems to me that the app is at fault here.


>
>They are blaming this on the fact that the devices have Mobile 2003
>and not Windows CE and that there is no way to fix the code to
>accommodate this. I am not a developer, so I can't dispute it, despite
>the fact that it just doesn't seem logical to me.

Who is "they" (Symbol, the software developers, or your client)?

I use native C/C++ to write my apps, and they definitely respond to
Enter keys sent from keyboard wedges. I even have a setting that lets
the user decide what key should be the trigger (some, but not all
wedges have a similar setting). And my apps run on many different
platforms, including HPC Pro, Windows Mobile 5 for Pocket PC, and
several of those "platforms with no name". I've never even tried to
write a web-based app, so I don't know how hard it is to get one to
respond to an Enter, or other, key. But I'm skeptical about the claim
that the platform is an issue.

Nitpick:
Mobile 2003 is based on the Windows CE operating system, so the phrase
"Mobile 2003 and not Windows CE" is technically impossible. However,
many companies (including Symbol) produce(d) devices that use Windows
CE but not Mobile 2003 or any other platform defined by Microsoft, and
no one has come up with an accepted term for these devices. So I
_think_ that is what they mean. If the software developer used this
phrase and is not from Symbol, than I'm curious what devices (brand
names) they have supported. For more about the term "platform", see:
http://www.opennetcf.org/Forums/topic.asp?TOPIC_ID=317


>
>Could some kind soul out there please provide some expertise please?
>Thanks!

Good luck.


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

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Thanks for the reply!


I think I may have over explained the issue. I'm going to explain it
again, for my own sake.

The client in question has a web page that hooks in with their
inventory software so they can print out an order, scan the bar code
into the field and it will give them an itemized list of everything on
the order. At that point they can start scanning the items and it will
tick them off until the order is complete. This page is written in
ASP/.net.

I have these scanners set up to send an ENTER after each barcode is
scanned, which should allow them to fly through orders without having
to interact with the touch screen at all, but naturally, that doesn't
work. Once you scan a bar code it just sits there, waiting for you to
press the submit button that is coded into the page. Even pressing
ENTER on the key pad has no effect. The developer is telling me that
this is because they are using Mobile 2003 on the scanners and claims
that in Mobile 2003, it simply isn't possible to modify code so that
it will detect the ENTER and have it focused on the SUBMIT button, as
you would expect it to work.

The entire premise of his statement makes zero sense to me. In this
day and age, I find it impossible that you couldn't modify code so
that it knew where that ENTER was supposed to go. I've asked several
experienced web developer friends of mine who seem pretty confident
that the guy doesn't know what he's talking about, but I'd like some
specific expertise from the Mobile 2003 side of things.

So basically, is there anything inherent in Mobile 2003 that would
prevent the above from being possible? Thanks again!

>> So basically, is there anything inherent in Mobile 2003 that would
prevent the above from being possible? <<

No way to know, but, in general, the problem is normally limited java
support... for example, the java is looking for an event that will never
be triggered by the ppc such as a java sensing that the user has moved
to the next field.

Again, he says it's your issue, we think it's his... from your report of
the vendor response, I'd do everything possible to avoid them as if this
is happening at startup without resolution, it's a red flag that future
problems and needs are going to be unaddressable.

Beverly Howard [MS MVP-Mobile Devices]

On 1 Feb 2007 06:16:45 -0800, chillzatl@gmail.com wrote:

>Thanks for the reply!
>
>
>I think I may have over explained the issue. I'm going to explain it
>again, for my own sake.
>
>The client in question has a web page that hooks in with their
>inventory software so they can print out an order, scan the bar code
>into the field and it will give them an itemized list of everything on
>the order. At that point they can start scanning the items and it will
>tick them off until the order is complete. This page is written in
>ASP/.net.
>
>I have these scanners set up to send an ENTER after each barcode is
>scanned, which should allow them to fly through orders without having
>to interact with the touch screen at all, but naturally, that doesn't
>work. Once you scan a bar code it just sits there, waiting for you to
>press the submit button that is coded into the page. Even pressing
>ENTER on the key pad has no effect. The developer is telling me that
>this is because they are using Mobile 2003 on the scanners and claims
>that in Mobile 2003, it simply isn't possible to modify code so that
>it will detect the ENTER and have it focused on the SUBMIT button, as
>you would expect it to work.
>
>The entire premise of his statement makes zero sense to me. In this
>day and age, I find it impossible that you couldn't modify code so
>that it knew where that ENTER was supposed to go. I've asked several
>experienced web developer friends of mine who seem pretty confident
>that the guy doesn't know what he's talking about, but I'd like some
>specific expertise from the Mobile 2003 side of things.
>
>So basically, is there anything inherent in Mobile 2003 that would
>prevent the above from being possible? Thanks again!

My programs accept Enter keys when running under Mobile 2003, so I'm
sure the answer to this question is NO. However, I have no idea about
constraints on web applications. Maybe they provide no way to detect
Enter. Or maybe that function doesn't work on Mobile 2003.

I started a thread called "ASP/.NET, Mobile 2003, and Enter key" to
see whether folks over there have a better answer.

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

Robert E. Zaret, eMVP
PenFact, Inc.
20 Park Plaza, Suite 478
Boston, MA 02116
www.penfact.com

Well, I'm curious. can you type (using the stylus and pop-up keyboard) into
the text field on the web form and hit enter and have it work? I can
certainly do that with many web sites on my PPCs. Google for example. I can
type a word into the search and hit Carriage Return and kick off the search.
I do not have to click a separate button, though one is provided.

It would be interesting to open the Google search page, and scan in a search
phrase, with the scanner software configured to supply a CR after the scan.
If it goes to searching, you know that your device is perfectly capable of
accepting a scan and CR to begin a process. If that is the case, then your
software guys need to go make it happen in their code.

--
Sven
MVP - Mobile Devices

<chillzatl@gmail.com> wrote in message
news:1170339405.849949.209440@q2g2000cwa.googlegro ups.com...
> Thanks for the reply!
>
>
> I think I may have over explained the issue. I'm going to explain it
> again, for my own sake.
>
> The client in question has a web page that hooks in with their
> inventory software so they can print out an order, scan the bar code
> into the field and it will give them an itemized list of everything on
> the order. At that point they can start scanning the items and it will
> tick them off until the order is complete. This page is written in
> ASP/.net.
>
> I have these scanners set up to send an ENTER after each barcode is
> scanned, which should allow them to fly through orders without having
> to interact with the touch screen at all, but naturally, that doesn't
> work. Once you scan a bar code it just sits there, waiting for you to
> press the submit button that is coded into the page. Even pressing
> ENTER on the key pad has no effect. The developer is telling me that
> this is because they are using Mobile 2003 on the scanners and claims
> that in Mobile 2003, it simply isn't possible to modify code so that
> it will detect the ENTER and have it focused on the SUBMIT button, as
> you would expect it to work.
>
> The entire premise of his statement makes zero sense to me. In this
> day and age, I find it impossible that you couldn't modify code so
> that it knew where that ENTER was supposed to go. I've asked several
> experienced web developer friends of mine who seem pretty confident
> that the guy doesn't know what he's talking about, but I'd like some
> specific expertise from the Mobile 2003 side of things.
>
> So basically, is there anything inherent in Mobile 2003 that would
> prevent the above from being possible? Thanks again!
>

On Feb 1, 10:10 pm, "Sven" <sejohann...@hotmail.com> wrote:
> Well, I'm curious. can you type (using the stylus and pop-up keyboard) into
> the text field on the web form and hit enter and have it work? I can
> certainly do that with many web sites on my PPCs. Google for example. I can
> type a word into the search and hit Carriage Return and kick off the search.
> I do not have to click a separate button, though one is provided.
>
> It would be interesting to open the Google search page, and scan in a search
> phrase, with the scanner software configured to supply a CR after the scan.
> If it goes to searching, you know that your device is perfectly capable of
> accepting a scan and CR to begin a process. If that is the case, then your
> software guys need to go make it happen in their code.
>
> --
> Sven
> MVP - Mobile Devices
>
> <chillz...@gmail.com> wrote in message
>
> news:1170339405.849949.209440@q2g2000cwa.googlegro ups.com...
>
> > Thanks for the reply!
>
> > I think I may have over explained the issue. I'm going to explain it
> > again, for my own sake.
>
> > The client in question has a web page that hooks in with their
> > inventory software so they can print out an order, scan the bar code
> > into the field and it will give them an itemized list of everything on
> > the order. At that point they can start scanning the items and it will
> > tick them off until the order is complete. This page is written in
> > ASP/.net.
>
> > I have these scanners set up to send an ENTER after each barcode is
> > scanned, which should allow them to fly through orders without having
> > to interact with the touch screen at all, but naturally, that doesn't
> > work. Once you scan a bar code it just sits there, waiting for you to
> > press the submit button that is coded into the page. Even pressing
> > ENTER on the key pad has no effect. The developer is telling me that
> > this is because they are using Mobile 2003 on the scanners and claims
> > that in Mobile 2003, it simply isn't possible to modify code so that
> > it will detect the ENTER and have it focused on the SUBMIT button, as
> > you would expect it to work.
>
> > The entire premise of his statement makes zero sense to me. In this
> > day and age, I find it impossible that you couldn't modify code so
> > that it knew where that ENTER was supposed to go. I've asked several
> > experienced web developer friends of mine who seem pretty confident
> > that the guy doesn't know what he's talking about, but I'd like some
> > specific expertise from the Mobile 2003 side of things.
>
> > So basically, is there anything inherent in Mobile 2003 that would
> > prevent the above from being possible? Thanks again!

Sven,

Thanks for the reply. The answer is yes, it works just fine like that.
I even took the time to pull up several pages and show them that yes,
it does work. I even went so far as to go to google, scan a barcode
and it accepted the carriage return and searched for the numbers in
the barcode, as expected.

At this point, I have zero doubts that it is completely possible to
modify their app so that it behaves properly on mobile 2003. The
developer either doesn't want to do the modifications or lacks the
knowledge to do it. It's unfortunate because the client wants this to
work and is now looking at buying an entirely new set of scanners
rather than pressure the developer to fix the app.

Thanks for everyones replies on this!