Can anyone tell me why a Visual Basic 6.0 app running on Windows XP embedded
would give a run time error 5 when calling one of the following functions?

Mid
Left
Trim
InStr


The application is packaged using the Package & Deployment wizard, and as
best we can tell (having exhaustively checked) all of the dependencies are
present and accounted for.  Any help appreciated.

What's "Windows XP *embedded*"?

Have you tried VBA.Mid, VBA.Left etc?

Mike

It's another version of Windows that lets you build XP on a component by
component basis, valuable for embedded environments where space is at a
premium.

I have, same result.


Show quoteHide quote

Show quote Hide quote As per Mike Warren's post, you are almost certainly missing components.
The easiest way is to install the VBRuntime:
http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5&displaylang=en

Which of course puts you into a catch-22. You are using Embedded because you
want to be small, yet to run stuff, you have to add components. After a
couple of times trying to uncover the exact components needed and install
them one by one - I have found it easier to load the whole package and then
go back and remove what is NOT needed IF necessary.

-ralph

What components could those be?  I've already specifically made sure to add
"VB 6.0 Run-Time" to the image.  What else could I be missing that would
cause functions like Mid and InStr to not work?  In any case, I downloaded
the file pointed to by the URL, and it did not fix the problem.

Show quoteHide quote

Try opening your VBP file in Notepad, find all lines that start with
'Reference' or 'Object' and post what you find here. We should be able to
help if we have that info.

Type=Exe
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\..\WINDOWS\system32\stdole2.tlb#OLE
Automation
Reference=*\G{00025E01-0000-0000-C000-000000000046}#4.0#0#..\..\..\..\Program
Files\Common Files\Microsoft Shared\DAO\DAO350.DLL#Microsoft DAO 3.51 Object
Library
Reference=*\G{6B263850-900B-11D0-9484-00A0C91110ED}#1.0#0#..\..\..\..\WINDOWS\System32\MSSTDFMT.DLL#Microsoft
Data Formatting Object Library
Reference=*\G{3D5C6BF0-69A3-11D0-B393-00A0C9055D8E}#1.0#0#..\..\..\..\Program
Files\Common Files\designer\MSDERUN.DLL#Microsoft Data Environment Instance
1.0
Reference=*\G{00000200-0000-0010-8000-00AA006D2EA4}#2.0#0#..\..\..\..\Program
Files\Common Files\System\ADO\msado20.tlb#Microsoft ActiveX Data Objects 2.0
Library
Reference=*\G{B3337DD4-0691-11D0-B075-00C04FD61157}#1.0#0#..\..\..\..\Program
Files\Microsoft Visual Studio\VIntDev98\bin\DTCRT.DLL#Microsoft DTC
Framework
Reference=*\G{78E93843-85FD-11D0-8487-00A0C90DC8A9}#1.0#0#..\..\..\..\WINDOWS\System32\MSDBRPT.DLL#Microsoft
Data Report Designer v6.0
Object={97917068-BB0B-4DDA-8067-B1A00C890F44}#1.0#0; rdchost.dll
Object={00028C01-0000-0000-0000-000000000046}#1.0#0; DBGRID32.OCX
Object={831FDD16-0C5C-11D2-A9FC-0000F8754DA1}#2.0#0; MSCOMCTL.OCX
Object={67397AA1-7FB1-11D0-B148-00A0C922E820}#6.0#0; MSADODC.OCX
Object={CDE57A40-8B86-11D0-B3C6-00A0C90AEA82}#1.0#0; MSDATGRD.OCX
Reference=*\G{0D452EE1-E08F-101A-852E-02608C4D0BB4}#2.0#0#..\..\..\..\WINDOWS\System32\FM20.DLL#Microsoft
Forms 2.0 Object Library
Object={F6125AB1-8AB1-11CE-A77F-08002B2F4E98}#2.0#0; MSRDC20.OCX
Object={BDC217C8-ED16-11CD-956C-0000C04E4C0A}#1.1#0; TABCTL32.OCX
Reference=*\G{56BF9020-7A2F-11D0-9482-00A0C91110ED}#1.0#0#..\..\..\..\WINDOWS\System32\MSBIND.DLL#Microsoft
Data Binding Collection
Object={648A5603-2C6E-101B-82B6-000000000014}#1.1#0; MSCOMM32.OCX

Show quote Hide quote Well.... you seem to be using MSDE. Is that installed on the "target"
system? Also looks like both DAO and ADO are in use. Are those packages
(MDAC and Jet) installed on the target?

I didn't recognize 'rdchost.dll'... According to the DLL Help Database
(http://support.microsoft.com/dllhelp/), that file is installed with the OS
so, if it's in your setup package, get rid of it.

Neither FM20.DLL or DTCRT.DLL are redistributable so, if you're using those,
the target PC must have Office installed. Note that FM20 alone is enough to
cause you severe problems.

-------<Canned FM20 Response>-------------
INFO: Usage and Redistribution of FM20.DLL
<http://support.microsoft.com/support/kb/articles/Q224/3/05.ASP>
MSForms components weren't designed to work with VB. There are several
licensing issues as well as the fact that they just don't work well..
You can't legally distribute that library in any way shape or form. The end
user *must* have this library correctly installed. It is installed as part
of Microsoft Office and a few other Microsoft packages. There is at least
one free way to download the library but that must be done by the end user.

If you use and distribute it anyway, below is what the end user will see...
Q241245 - PRB: "Error 7 - Out of Memory" Error Message From Visual Basic
Application Using FM20.DLL
<http://support.microsoft.com/support/kb/articles/Q241/2/45.ASP>
-------</Canned FM20 Response>-------------

Your package surely needs to install TABCTL32, MSCOMM32 and all other ocx's
shown in the list. The database support needs to be installed using it's own
installer (many, many files) fm20 needs to go away, install Office on the
target PC if you need dtcrt.dll.

Your points are well taken, and I shall be doing these things forthwith.
However, even without MSDE installed, the numerous database calls made in
the code before it crashes are just fine.  ADO is indeed installed, and that
seems to be sufficient.

Show quoteHide quote

http://www.microsoft.com/downloads/details.aspx?FamilyID=bf9a24f9-b5c5-48f4-8edd-cdf2d29a79d5&displaylang=en
Wow! That's a bit silly isn't it.

Well, here is a couple of guesses...
1) Any chance you might have named something in your program like "mID" or
"InStr". Something that slipped by when compiled.
2) Building on the same idea - it is just possible that the error you are
getting is bogus. Maybe the original program was compiled in error.
3) Are you possibly including some incompatible "system files" in your
package? Remove everything from the setup that isn't absolutely written by
your team.
3) Go back and recompile your app using pcode. (It will be smaller and
faster)

hth
-ralph

Ralph wrote:
Pedant warning/

The former, but not necessarily the latter...unless you mean compile
time, not run-time performance...

Well, one does need to try it.

Generally PCode for most common VB applicatins is faster - but it depends on
what the app is doing. Heavy-duty computations, parsing, hand-rolled
drawing, etc. often benefit from being compiled to native code.
Client/Server apps that are merely collecting data, doing validation, and
data access libraries (ADO/DAO) to update a database run faster in PCode
than a native-compiled one.

It is a myth that PCode is *always* slower. But like everything else in
computing - one needs to test in THEIR problem domain.

(But it is 5 to 1 you will be pleasantly surprised. <g>)

-ralph

Ralph wrote:
Show quoteHide quoteI suppose that comes w/ the problem domain---I don't do much of anything
that isn't compute-intensive so my experience is <heavily> weighted in
the opposite direction.  P-code is smaller executable and generally
quicker compile time (although that rarely is a consideration) but is
universally slower at runtime for things I'm at all likely to do.  I
generally do the development in VB while doing the UI and then move the
computations to a Fortran DLL which can add an additional factor of
anywhere from 1.x to as much as 5 depending on how heavily a particular
app is reliant on things like complex (as in non-zero imaginary
components) or other math intrinsics...

Show quote Hide quote No, it doesn't sound like you would 'gain' much with PCode. <g>

The VB runtime has a few highly optimized functions, but in general uses the
standard math library in the crt and does it thru an extra layer of
indirection.

Who's fortran are you using? Have you ever investigated some of the 3rd
party math libraries out there? The only package I have ever used was
Statisica. The performance gained using a dedicated math library has always
amazed me.

-ralph

Ralph wrote:
Show quoteHide quoteW/ VB since it is by definition "Winders only" I almost exclusively will
develop the Fortran using CVF (Compaq (nee Digital) "Visual" Fortran)
which, unfortunately, is no longer being supported as Compaq sold the
compiler group to Intel.  At some point, I may migrate to another
compiler but so far what known bugs are in CVF are not show-stoppers.
When F2003-compatible compilers become available then there may be
incentive enough w/ newer features to upgrade at that point.

W/ the Professional version of CVF came included the Visual Numerics
(nee IMSL) math and stat libraries which I use extensively.  The math
libraries in particular are tuned version of BLAS/LINPACK code w/ a
standardized error-handling interface that is convenient.

There is, of course, a "veritable plethora" of Fortran code catalogued
at Netlib accessible there or through the NIST/ORNL GAMS interface that
can help in many problem areas.  For VB'ers, I have often suggested that
as a source of computational algorithms/software as (particularly the
F77 dialect) Fortran syntax is so similar to "pure" BASIC and w/ the
column major array structure of both languages, interlanguage calls are
quite easy.

I know of Statistica but have never used it so can't really comment
knowledgeably about it.  I became aware of and began to use IMSL back in
the mainframe days in the mid/late 60s when I first went to work out of
school and have used it almost continuously since on CDC/Cray/DEC
(10/20, VAX, PDP)/IBM/Amdahl until the first PC/AT 16-bit installation
from which gradually more and more PC compute power led to moving more
and more apps to the desktop.  Consequently, at the present time,
familiarity trumps alternate routes.

Matlab is another of my key tools especially for fast prototyping and
data display/visualization although I have never used it for a
production system as many do.

See if this helps:

Best practices for deploying Visual Basic 6.0 applications
http://support.microsoft.com/default.aspx?scid=kb;en-us;830761



Show quoteHide quote

Show quote Hide quote Since Error 5 means "Invalid procedure call or argument", there are dozens
and dozens of ways to raise that error.... fwiw, Setting focus to a control
that's not ready for focus is one of the most common causes. You might want
to add some logging capability and track the arguments you're passing to
those methods. Hopefully, you have error traps in place anyway, so logging
shouldn't be too terribly difficult.(fyi, I've never tried VB on an embedded
OS... seems like there shouldn't be a problem... could be wrong.)

Show quote Hide quote I'm with Mike in that I think you should clarify what you mean by "Windows
XP embedded". I gotta admit that I'm not sure what that means.  Apparently
Ken knows what you mean, so it must just be me and Mike (but I'd guess
others aren't sure either). My guess is that you've got a multi-OS system?

In any case, error 5 is "invalid procedure call or argument" and all kinds
of things can cause that.  I take it that you don't get this error when
running within the IDE on your dev computer? And probably not if you run the
compiled app on your dev PC? But, if so, then the first, I'd check is the
References dialog.  Ensure that no libraries are listed as "Missing". If no
problems there, verify that somewhere in your code you're not using (or at
least not qualifying with an object reference), some variable, procedure,
property, etc. that has the same name as any of the functions you listed.
But even that *should" cause an error when run on your dev PC within VB.

The only other thing I can guess is that SOME file is missing or outdated on
the target PC.  You mentioned PDW.  Well, PDW is not the greatest tool to
use anymore for creating setup packages.  It's outdated, and therefore has
problems with later versions of Windows.  Simply put, files that you THINK
are getting installed or updated may not be.  You said that you
"exhaustively checked".  Did that include versions of files (as opposed to
just checking that the file was there)?

And then to get back to this "embedded" Windows XP. Maybe there are issues
with that?

MikeD wrote:
Win XP Embedded is a version of XP pro that OEMs can build
for themselves from components. This makes a more compact
OS for devices rather than general purpose computers.

The problem with XPe is that the right components must be
added for a particular program to work (dependencies).

To the OP: If your VB program works in XP Pro then the cause
must be something missing or a configuration problem in your
XPe build.

I'm not conversant with VB (stopped using it a VBDOS) but
would expect the functions which you are having problems with
to be included with the base libraries of VB.

-Mike

Heck... if you stopped at VBDOS, you stopped when all the fun started <g>...
too late now though. The fun's over ;-)

On Wed, 12 Oct 2005 15:19:56 -0400, "Robert Dormer"
<r.dor***@www.digdevinc.com> wrote:

I've been following this thread, and have one more suggestion.

At the top of every Module, Form etc  put:

   Option Explicit : DefObj A-Z

It is just possible that you have some Deviants (variants) turning up
as a result of (ahem) incomplete declarations, and under certain
circumstances they are confusing things.

Another point, always test with Ctl [F5], in some shops just using
[F5] is a sackable offence.

Also, sometimes VB is not totally honest with its Errors, when it gets
very confused it can also get misleading.

excel versions in Vb 6
Application error "Permission Denied" only under WinXP-SP2
VB6 Variable Name as String
format number again
Picture Box Question
Activex EXE help
Dependency walker and custom ocx.
Lexical analysis
VB IDE Not Integrating Visual SourceSafe Problem
creating dll's, using in other projects... problem when recompile dll... help please!!!