Missing SUB

[Gary Beene]

In my app I call a sub "ShowNameDialog", which I cannot find in my BAS nor INC files. I also cannot find it in the Jose includes that I use. PBCodec does not report it either.

When I ran the app code that executes ShowNameDialog, my program actually runs a sub called "ShowEntryDialog".

I have no idea why calling out ShowNameDialog (which does not exist) results in running ShowEntryDialog. I have no Macros which would substitute one for the other.

Any suggestions on what I am missing?

[Mike Doty]

Any dll or sll?
Shelled to another program?
Cross-linked files chkdsk /f
Code is on another drive or in another folder?
Alias in declare statement?

GLOBAL gs AS STRING
#INCLUDE "\roca\windows.inc"
#INCLUDE "win32api.inc"

FUNCTION PBMAIN
 ShowNameDialog
 ShowEntryDialog
 ? gs
END FUNCTION

SUB ShowNameDialog
 gs += FUNCNAME$ + $CRLF
END SUB

SUB ShowEntryDialog
 gs += FUNCNAME$ + $CRLF
END SUB

[Gary Beene]

Howdy, Mike!

Thanks for the suggestions!

I use a DLL, but from cstools. Their INC file does not show a sub called ShowNameDialog.
I use SHELL only on demand - nothing that ought to support compilation of an unknown Sub.
All my includes are in the EXE folder
No alias by either of the Sub names

The idea that another app just happens to have a sub by the name of what I use but cannot find, with the same arguments would seem unlikely.

Still a mystery.

It's funny that PBCodec does not show the ShowNameDialog sub. In it's report, the string ShowNameDialog doesn't appear at all.

[Mike Doty]

A project file or an include file loading another include file?
Might use notepad++ or some other program to search for "ShowNameDialog" in all your .bas and .inc files.

[Frank Rogers]

I would use Gotcha from Pierre and search the folder or drive for the string.

[Stuart McLachlan]

WHat happens on compilation if you create and call a simple SUB ShowEntryDialog at the start of your application?

[Mike Doty]

Might use File, Save File As and double check where each of the source files are saved.

[Chris Boss]

Look for a macro !

One could define multiple macros with different names for a subroutine, but then call the same subroutine defined by the macros.

Macros are text substitution, so would be easy to not notice.

[Gary Beene]

Howdy, Mike!

I have something like 50 or so INC files of my own. I used gbSearchLite on them all, plus on all backup copies, including subfolders. No such string. If an include calls another include that has ShowNameDialog, in it, gbSearchLite would not see it. .

It's time for me to get out my earlier utility that indexes every BAS and INC on my entire C:\ drive and see if ShowNameDialog shows up. It has to be somewhere for the compiler not to puke. For that matter, if I start at C:\ then gbSearchLite will do it as well. Might take several minutes but I'll give that a try while I go pop some popcorn!


Howdy, Chris!

I use no Macros. I looked for those with gbSearchLite as well. The CSTools INC files had some, but none by the name of the unknown SUB.


Howdy, Stuart!

It compiles without error.


Howdy, Frank!

The gbSearchLite I mentioned searches within all BAS and INC files in a folder. It found no files with ShowNameDialog in them.


It's going to be something simple but it eludes me so far. For compile not to fail, it has to find the ShowNameDialog somewhere.

[Dave Biggs]

I use a DLL, but from cstools. Their INC file does not show a sub called ShowNameDialog.

ShowNameDialog is exported by cstools's DLL but not listed in their .INC file?

[Gary Beene]

Howdy, Dave!

Could be but they usually name their subs differently - recognizable as a CS sub.

At one time my code did have a sub ShowNameDialog - long since removed and not found in any of my backups.

I just searched the 10K or so BAS/INC files on my PC and found no ShowNameDialog string in any of them.

[Dave Biggs]

Could be but they usually name their subs differently - recognizable as a CS sub.

Exported routines are easily checked with Dependency Walker or Torsten's PB utility posted here

[Gary Beene]

Resolved!

I called out ShowNameDialog in one of my include files, but that include file was (correctly) **NOT** listed in my main BAS or any of the includes for inclusion in compilation of my app.

I had unintentionally left the unused INC in my EXE folder and that's why my search returned ShowNameDialog as being present in my app code - when in fact it was not part of the EXE compilation.

That explains why PBCodec did not list it.

Thanks for all the responses - they helped me narrow down the search to find where I had gone wrong!

[Stuart McLachlan]

WTF, all this because you ran some sort of application that listed every Sub in every .inc /.bas file in a directory whether the file was used or not?

What exactly did you mean by "When I ran the app code that executes ShowNameDialog" ?

[Gary Beene]

Howdy, Stuart!

Yep, I did exactly that. I thought I had removed all unused INC files from the EXE folder. I was wrong.

Since I thought the INC was included in my app I believed the app was running ShowNameDialog. I was wrong.

You'll recall that I mentioned running PBCodec, which told me that ShowNameDialog was NOT a function found in the app BAS nor its includes. Despite that clue I did not discover there was an unused INC in the EXE folder.

What caught my attention was I saw that the used INC and the unused INC each had a function by the same name, which I ran across by listing all the functions in all code files in the EXE folder. The compiler would have burped on that, leading me to find the unused INC.

[Michael Mattias]

why my search returned ShowNameDialog as being present in my app code - when in fact it was not part of the EXE compilation.

With the code removal feature in use, the procedure would be removed from the executable anyway so any check of the EXE/DLL would not show the procedure (unless it's used somewhere).