When I compile with 2.00.575 my app runs ok, but when I try to run it
with xppdbg.exe I get this error msg

"The procedure entry point _conTypeAV2 could not be located in the
dynamic link library xpprt1.dll."

When I compile with 2.00.560 the debugger runs ok.


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
 Spell-X  Spell Checking for Xbase++

Hi Clayton,

Please ensure that the Xbase++ versions match.

Because your application runs OK, the culprit seems to be the debugger
which does not stem from the proper version.

"The procedure .... could not be located ... in xpprt1.dll" means that an
export which is expected by a target (dll or exe) that was created with 
Xbase++,
can not be found in xpprt1.

Because your application exe and dlls have been properly linked, it is the
debugger that does not match.

With my best regards,

Andreas Herdt
Alaska Software

-------------------------------------------------------------------- 

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
-------------------------------------------------------------------- 


"Clayton Jones"  schrieb im Newsbeitrag 
news:m26nkadjcnfqpe47k3onqgchtqacrdlpq2@4ax.com...

When I compile with 2.00.575 my app runs ok, but when I try to run it
with xppdbg.exe I get this error msg

"The procedure entry point _conTypeAV2 could not be located in the
dynamic link library xpprt1.dll."

When I compile with 2.00.560 the debugger runs ok.


Regards,
Clayton

Clayton Jones   www.cjcom.net
Top-Down Library for Xbase++
X-DBU Database Utility
X-MEMO Memo Field Replacement
Spell-X  Spell Checking for Xbase++

Hello Andreas,

Thanks for your reply.

>Please ensure that the Xbase++ versions match.
>
>Because your application runs OK, the culprit seems to be the debugger
>which does not stem from the proper version.
>
>Because your application exe and dlls have been properly linked, it is the
>debugger that does not match.

I double checked everything and all the proper files are being used,
including xppdbg.exe.  I need to explain what I'm doing so you'll
understand the situation - sorry, this will take a bit of explaining.

I do not use the Workbench because I don't like working in it.  I
prefer to use my own editor, the Top-Down IDE/Form Designer, etc.  The
only thing I use the Workbench for is to download and install updates.
The Workbench was initially installed without changing the traditional
Xbase++ env settings, PATH, etc.

I have always installed Xpp on another partition, G: in this case,
where many of my programming tools reside.  So the INCLUDE path, for
example, is G:\ALASKA\XPP32\INCLUDE.  All of these paths are still in
effect.

After installing a new update, 575 being the latest, I create a new
folder for it on G:, in this case G:\AK2.00.575, and underneath that
is \XPP32, and underneath that are \bin, \book, \include, \lib,
\runtime, etc.  It is an exact replica of the traditional installation
folders.  Then I copy into those folders all of the files from the
corresponding 2.0 installation folders on drive C:.

When I want to work in a particular version, I rename the folder to
\Alaska.  For example, if I've been working in 575 but now need to
work on a project that is still in 1.90.355, I do two things:
 1) Change G:\Alaska to G:\AK2.00.575
 2) Change G:\1.90.355 to G:\Alaska

And immediately all the 355 files are in effect.  I've been doing it
this way for years, way back into the early versions (1.2, 1.3, etc).
It's very quick and easy and has never been a problem of any sort.

When 575 was released I began using it and didn't have any problems.
But the other day I needed to use the debugger for something and when
I tried it I got that error msg.  As a test I switched back to
2.00.560 (using my method) and the debugger works fine.  I just tried
575 agsain to be sure (erased all obj files and recompiled everything)
and the same error happens.  

I compared all the files in the folders to the ones in the \xpp20
folders on C: and all the date stamps match, and all the files are
there, nothing missing.  The dates of xppdbg.exe and xpprt1.dll are
02/17/15.

I'm wondering if you have tried running the 575 xppdbg.exe on a
project from a command line?  If not, can you please try it and see if
you get the same error?  If it works ok for you then I'll have to
figure out what's wrong at this end, though I've already tried
everything I can think of.


Thanks very much,
Clayton


Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
 Spell-X  Spell Checking for Xbase++

Clayton Jones wrote:

> If it works ok for you then I'll have to
> figure out what's wrong at this end, though I've already tried
> everything I can think of.

Did you try to start the debugger via dependency walker to find out what
DLLs are actually loaded - and to be more precise, from where?

You could also use procmon from sysinternals to find this out, but I prefer
to use dependency walker.

Thomas

Hi Thomas,

>Did you try to start the debugger via dependency walker to find out what
>DLLs are actually loaded - and to be more precise, from where?
>
>You could also use procmon from sysinternals to find this out, but I prefer
>to use dependency walker.

I'll be happy to try it but I don't know how because I've never used
it.  Can you explain how to use it?

Thanks,
Clayton

Clayton Jones wrote:

> I'll be happy to try it but I don't know how because I've never used
> it.  Can you explain how to use it?

Of course 

DISCLAIMER: I have not used this for ages - I hope it still works as
expected for newer Windows versions 

Download from here: http://www.dependencywalker.com/

Click on File -> Open, select the executable you like to trace (in your
case, the debugger)

Dependency walker then loads the process and first shows if statically
linked libs are missing (which is the case almost all the time)

Make sure you have View->Full Paths checked

You can check now in the "Module" pane if there are any dependencies on
wrong/unwanted paths.

After that you can start profiling the application via the Profile menu (or
press F7.)

Dependency walker then starts the application and shows also all
dynamically loaded DLLs.


HTH
Thomas

Clayton,

one more hint - to be able to trace x86 programs you have to use the x86
version of DW... tracing is disabled when loading x86 executables with the
x64 version.

Thomas

Andreas and Thomas,

Problem solved.  I had forgotten that I had copied the 560 runtime
DLLs into that project folder.  After removing them the 575 debugger
worked ok.  What's odd is that the 575 compiled app worked ok with the
560 runtime DLLs.  Strange.

Anyway, I'm glad to get this resolved and I apologize for the false
alarm.  Thanks for your help.


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
 Spell-X  Spell Checking for Xbase++

Hi Clayton,

That's great.

Your description of what was the problem perfectly explains the false
behaviour.

The procedure entry point which was complained simply is not requested
by all Xbase++ application. The debugger requires those symbols to be
available.

Just for my curiousity. How did you resolve the issue. Was it with the
help of the dependency walker or was it a close look on what is deployed
in the executables folder?

With my best regards,

Andreas Herdt
Alaska Software

-------------------------------------------------------------------- 

Technical Support: support@alaska-software.com

News Server: news.alaska-software.com
Homepage: http://www.alaska-software.com
WebKnowledgeBase: http://www.alaska-software.com/kbase.shtm

Fax European Office: +49 (0) 61 96 - 77 99 99 23
Fax US Office: +1 (646) 218 1281
-------------------------------------------------------------------- 


"Clayton Jones"  schrieb im Newsbeitrag 
news:um84lat7d8k60b4vjjm5nvd1s957gp37rv@4ax.com...

Andreas and Thomas,

Problem solved.  I had forgotten that I had copied the 560 runtime
DLLs into that project folder.  After removing them the 575 debugger
worked ok.  What's odd is that the 575 compiled app worked ok with the
560 runtime DLLs.  Strange.

Anyway, I'm glad to get this resolved and I apologize for the false
alarm.  Thanks for your help.


Regards,
Clayton

Clayton Jones   www.cjcom.net
Top-Down Library for Xbase++
X-DBU Database Utility
X-MEMO Memo Field Replacement
Spell-X  Spell Checking for Xbase++

On Tue, 12 May 2015 20:01:23 +0200, Andreas Herdt wrote:

>Just for my curiousity. How did you resolve the issue. Was it with the
>help of the dependency walker or was it a close look on what is deployed
>in the executables folder?

Didn't use the DW, I solved it before I got Thomas' post.

One of the tools I use is Ztree, a file management program which I use
for copying/moving/deleting files, creating/renaming folders, and many
other chores.  It's a fantastically good program which I have come to
depend on.  One of the features I like is a very quick and easy file
filter.  I have a number of standard filters I use over and over, one
of which filters out obj/lib/dll files and some others, leaving mostly
prg, ch, txt, etc.  I use it while programming because it simplifies
the view and allows me to find things and get my work done more
quickly.

Normally I don't copy the runtime DLLs into project folders, but in
this case I did, some months ago, because I was working in the TD demo
app with 560 and at the same time was doing some contract work on
another project in 355.  At one point while working in the 355 project
I wanted to see something in the TD app and couldn't run it because
355 was in effect.  So I copied the 560 runtime files into the TD
folder and was able to run it while 355 was in effect.  And then I
forgot about it.

Later I began using TD with 575 and it ran fine, even with the 560
DLLs, so I was not reminded of them.  But when I needed the debugger a
few days ago it wouldn't run, and the error msg wasn't the usual one
that tells you you're using the wrong version.  Yesterday I was
looking in that folder to see which XbpPdf DLLs I was using and
switched the filter to show DLLs and there were all the 560 runtime
files!  Duh.  It didn't occur to me to check that because it's not
something I normally do.

Lesson learned.


Regards,
Clayton

Clayton Jones   www.cjcom.net 
 Top-Down Library for Xbase++
 X-DBU Database Utility   
 X-MEMO Memo Field Replacement
 Spell-X  Spell Checking for Xbase++