#RESOURCE problems with Error 478 : Resource file error

[Cliff Nichols]

I have always used "Relative" paths when compiling my code (mostly with Resource files) but now that I am trying to switch more to the PB compiler commands like

#RESOURCE BITMAP, Splash_Image, "./Resource Files/Cosmos Intro.bmp"

Since my code is on a USB stick that I carry between work and home the absolute path can change, so I always stuck with a relative path and it always seemed to work when I precompiled a *.pbr or a *.res

Using #RESOURCE however I get

Error 478 in (0:000): Resource file error

but appears to happen "Randomly" (but once it does, then it always does until I close PB completely and start again.

So Question #1 before I continue with what "I THINK???" might be happening?????

Has anyone seen this sort of problem on their machine before???


I will try to work up a demo to post shortly and then what I think might be a problem? or if I find out from others that it may be a bug to submit to PB???

[Cliff Nichols]

Here is a compilable example attached is the full code and the folder structure and the resource (although I can not get it to cause the error just yet)

The code basically consists of the following (I hard-coded, just to get the example out)

#COMPILE EXE
#DIM ALL
#INCLUDE ONCE "Win32Api.inc"
#RESOURCE BITMAP, Splash_Image, "./Resource Files/Cosmos Intro.bmp"

FUNCTION PBMAIN () AS LONG
     Splash_Load %HWND_DESKTOP
END FUNCTION

CALLBACK FUNCTION Splash_Callback
     SELECT CASE CBMSG           'Determine what the event is
          CASE %WM_INITDIALOG     'If initializing (opening the TerminalSimple)
          CASE %WM_SYSCOMMAND
               IF (CB.WPARAM AND &HFFF0) = %SC_CLOSE THEN   'Must get the CBWPARAM first or this query-unload equiv will not work
               END IF
          CASE %WM_DESTROY
          CASE %WM_ShowWindow
          CASE %WM_CtlColorStatic
          CASE %WM_GetMinMaxInfo
          CASE ELSE
     END SELECT
END FUNCTION

FUNCTION Splash_Load ALIAS "Splash_Load"(Parent_Window AS LONG) EXPORT AS LONG     'Load main program
     LOCAL hWnd AS DWORD
     DIALOG NEW PIXELS, Parent_Window, "Velmex, Inc", %CW_USEDEFAULT, %CW_USEDEFAULT, _
                         500, 135, %WS_CAPTION OR %WS_CLIPSIBLINGS OR %WS_SYSMENU OR %WS_MINIMIZEBOX, %WS_EX_CONTROLPARENT TO Hwnd

     CONTROL ADD IMAGE, Hwnd, 1, "Splash_Image", 0, 0, 334, 71
'     DIALOG SHOW MODELESS Hwnd, CALL Splash_Callback
'     sleep 5000
     DIALOG SHOW MODAL Hwnd, CALL Splash_Callback
END FUNCTION

I will post some of my thoughts next as to what I can only guess what might be happening when I get the error?

[Cliff Nichols]

Thought #1.....
I seem to remember that if you use a resource (or get a handle to something in a resource) then you must make sure it is destroyed before ending a program. (PB usually handles this, but maybe sometimes it misses and I did not clean up after myself???)

Thought #2.....
Since its on a USB drive (I have heard that not always does Windows make it changes to the USB files until it "Gets around to it" or I force it by ejecting the drive before yanking it???
(This is much less likely cause I just compiled it, made a change and just trying to recompile it)

Thought #3....
Antivirus...anti-malware??? (They may be grabbing a handle to my file and not releasing it sometimes so when I recompile the previous handle is still in use???.....Even less likely cause its the 1st thing I think of when I have a compile error of some sort that can not be explained)

Thought #4....
I compile fine....I close program and open another instance of PB to look at Win32Api.inc for something, then switch windows back and boomer I get the error???? (Making me think that now Windows thinks the relative path is the path to the Win32Api.inc and not the path to my USB drive???)

Thought #4 I think is more likely but does not always happen either so again it has me wondering?????

and Thought #5......drum-roll please.....
Has anyone seen a similar problem??? and why oh why can I not get snippet code to replicate the problem???
(I am guessing if all else fails, then my true problem is somewhere else in my real code and not just when it rears its ugly head)

[Ribeiro Alvo]

Cliff already tried this:

#RESOURCE BITMAP, Splash_Image, "/Resource Files/Cosmos Intro.bmp"

[Cliff Nichols]

Ribeiro Alvo,
Did I miss something???
It works fine until I get the compiler error so wondering what I did when I get the compiler error?

I could compile 12x I could compile 200x but when it occurs then it always occurs until I close everything (and sometimes a reboot) so it all leads me to some handle somewhere not releasing until I kill whatever is holding it open???

PB-Compiler?? (PB-Resource???...I can only guess is a pre-compiler to compile a resource and then compile the code?? without me intentionally needing to do it???)

Something else???

[Michael Mattias]

Try it with a fully qualified path to the BMP file. If that works, the problem is either in your current directory (the "." does that), or the compiler's #RESOURCE statement does not handle partially or relatively-qualified file names. (Or at least does not handle 'well').

If you are using the PB IDE your "current directory" changes as you change files so that might be your problem here. Not that you should have to exit and start over ... I would think you should get a compiler error for "File named in #RESOURCE directive not found" but I have found other problems with the #RESOURCE directive ... well not "problems" so much as "inadequacies" - but I would not be shocked if there were genuine "issues" here.

MCM

[Ribeiro Alvo]

At the start of the path, delete the point.

"/Resource Files/Cosmos Intro.bmp"

Not

"./Resource Files/Cosmos Intro.bmp"

If that does not work, follow the instructions of Michael

[Cliff Nichols]

Thanks guys...I tried that before but have to re-replicate again
at one point when I changed my "/" to "\" then it would work again until it did not, and then if I switched back to "/" it would work again...

Thats why I am curious if its all a relative addressing issue?? or if I might have done something that I did not realize that fixed the problem?

Or better yet just the idea that I am not the only one to see the problem???

MCM is right...I could just change my absolute path depending where I am....but I am more curious why relative would fail...if/when it does???

[Michael Mattias]

For one thing, "." is easily changed!

[Cliff Nichols]

Update:

I noticed this morning at work that I have not had any problems with the #RESOURCE command, and the thought hit me that everytime that I can recall the problem occurred at home.

Tonight I got home and on the very 1st compile I got the problem again

This got my "Troubleshooting mind" wondering (which I usually have to do with my users when I am not there to see a problem they are attempting to describe and no clue how to describe it)

Troubleshooting "Rule-of-Thumb" Question #1....."WHAT Changed?!?!?!?!?????"

1a> Home computer is faster than work computer so my thought about speed or actually writing to the USB drive could not be the problem.

1b> USB is slower than direct to hard drive, and I don't think I ever got the problem when compiling to hard drive

1c> Code has not been modified since I left work, and my 1st attempt to compile at home so that can not be it.

1d> Following the above possibilities the 2nd "Rule-of-Thumb" question should be "Whats DIFFERENT?"??????????
Possible Ans.) AH-Haaaaaa.......at work the USB drive was plugged into the computer directly, but at home it is plugged into an old hub I have had for years (and sneaky suspicion may be USB 1.0 and not whatever version that USB speeds are up to now days) leading me to start to wonder if the error I am getting is really a timeout error creating the resource and not just a vaguely covered generic "Resource Error" that I read???

I went on to re-route some cables and plugged the USB drive directly into the computer and so far after several recompiles I have not hit the problem yet......so crossing fingers and hoping I have the correct answer?

[Tom Hanlin]

Michael's got a "." ...no strong clue, although it sounds a little like a possible path problem. IDK, can you still invoke PBRES? It's obsolete, but it was pretty solid before Bob decided to pull resource management into the compiler.

[Cliff Nichols]

Hi Tom,
I do not think I had any problems compiling the resource separately, but now that I have a strong inkling that the core problem might be a timeout occurring if I am plugged into an old USB 1.0 hub, I can test the theory more clearly.

[Emanuele Colombo]

Does anybody solved the problem?
I had the same "Resource file error", randomly.

[Gary Beene]

Hey Emanuele!
I must have missed this post back in Dec when Cliff started it.

I get the error randomly all the time - perhaps a hundred times over the last year! Usually I just recompile and it goes away, but I have real idea why. I've not seen any pattern to suggest when the error will trigger.

I've even had it happen with the scintilla DLL. I like to keep the DLL in a subfolder, which always works at first on a new app. Then at some point I have to move the DLL to the same folder as the EXE. Don't know why.

It's one of those minor annoyances who solution keeps getting pushed to the back burner - it's easier to just repress Compile than go figure out what happened.

[Michael Mattias]

>I've even had it happen with the scintilla DLL. I like to keep the DLL in a subfolder

I have a special folder which I added to my path..

D:\Utility\DLLs>dir
 Volume in drive D has no label.
 Volume Serial Number is 049A-2E6F

 Directory of D:\Utility\DLLs

10/22/2013  05:56 PM    <DIR>          .
10/22/2013  05:56 PM    <DIR>          ..
11/18/2008  03:10 PM            20,992 cgsscc20.dll
06/27/2006  04:27 PM            18,944 Copy of HilExit1.dll.txt
04/21/2005  07:18 PM           139,264 ddoc.exe
02/14/2003  03:17 AM            64,466 ddoc16.dll
10/08/2003  03:27 AM           152,576 ddoc32.dll
10/08/2003  03:27 AM           139,776 ddoc_19e.exe
09/08/2003  03:31 AM           454,656 ddoc_jpg.dll
03/02/2010  07:06 PM           541,696 EGRID32PRO.DLL
02/09/2007  11:17 PM           515,584 EGRID32PRO_3.28.10.DLL
06/27/2006  04:27 PM            18,944 HilExit1.dll
11/23/2006  01:28 PM           786,432 libharu.dll
10/18/2004  04:25 PM            49,152 md5sum.exe
06/10/2003  08:45 AM            33,280 modlist.exe
11/01/2001  03:10 AM            61,952 Ptree32.dll
11/08/2011  06:56 PM            75,264 TSEDIAPI.DLL
10/16/2003  08:13 PM            45,056 TSEDIAPI_3B.dll
06/23/2003  03:56 PM            44,544 TSEDIAPI_3_0_2.dll
11/13/2006  01:20 PM            47,616 tsediapi_3_1_1.dll
03/04/2007  04:11 PM            50,176 tsiig022.dll
03/04/2007  04:16 PM            51,200 tsiig031.dll
05/11/2007  10:39 AM            46,080 tsiupgrade.dll
01/17/2007  03:36 PM            48,128 tsiupgrade1.6.dll
09/21/2006  03:39 PM            43,008 tsiupgrade15.dll
12/20/2006  05:06 PM            82,432 tsixml00.dll
05/10/2003  09:50 AM            82,432 tsixml00_1_1_1.dll
10/22/2013  05:53 PM            42,496 TSI_LOGINORACLE.DLL
10/30/2002  01:21 PM           246,424 unicows.dll
07/31/2012  01:07 PM            20,992 usncrypt.dll
06/24/2005  07:43 PM            34,816 usncrypt_1_6.dll
05/13/2007  02:09 PM            35,328 usncrypt_1_8.dll
05/06/2008  04:37 PM            37,376 usncrypt_1_9.dll
08/01/2008  09:00 AM            20,992 WinMsg.dll
08/22/2009  10:27 AM           236,032 X096A1API.dll
05/07/2009  03:27 PM           224,256 X096A1API_2.3.3.dll
07/29/2005  02:55 PM           210,432 X096A1API_v125.dll
08/11/2005  07:43 PM           217,088 X096A1API_v200.dll
08/19/2005  04:56 PM           218,112 X096A1API_v210.dll
05/07/2009  03:31 PM           226,304 X098A1api.dll
08/12/2005  07:10 PM           218,112 X098A1api_v200.dll
08/19/2005  07:34 PM           219,136 X098A1api_v210.dll
02/26/2009  09:59 AM           226,304 X098A1api_v230.dll
06/29/2005  04:46 PM           211,456 X098A1_v124_api.dll
08/15/2005  06:43 PM               344 x09xapi.ini
07/12/2002  07:48 PM           126,976 xmlparse.dll
10/22/2013  05:57 PM             4,171 _index.txt
              45 File(s)      6,390,797 bytes
               2 Dir(s)  63,748,198,400 bytes free

D:\Utility\DLLs>

_index.txt:

_index.txt for C:\Utility\Dlls

4/08/03 Created folder and added to path
09/03/07 rearranged to put all entries for same file together like product version logs. 
02/26/08 Added entry for LIBHARU. Note that this file does not have a version resource 
         and you have to select by size. LIBHARU 2.0.8 size = 768K
12/1/11  updated EGRIDPRO DLL.

DDOC.EXE and DDOC16/32. DLL

   04/19/03 Added ddoc.exe, ddoc32.dll, ddoc16.dll (v 1.9c)
   10/21/03 overwrote all ddoc with version 1.9E
   12/7/04  overwrote ddoc 1.9e with 1.9.5.1 (OEMVersion=Tal Systems (001)))
             fileversion="1.9e(1)"
   3.29.06  Overwrote ddoc.exe 1.9.5e1 with 1.9.5e2  (wider bookmark control)

TSIXML00.DLL and XMLPARSE (expat parser)

   05/10/03 Added TSIXML00.DLL v 1.1.0.1
   05/10/03 Added XMLPARSE.DLL (expat parser) No version info dated 7/12/02 size 126,976
   12.20.06 Changed tsixml00.dll to version 1.2.0 (handle encoding not supported by expat parser).

MODLIST.EXE   
    06/12/03  Added MODLIST.EXE v 1.0.0

TSEDIAPI.DLL
   04/08/03 installed tsEDIAPI.DLL  v 3.0.0
   6/20/03  Updated TSEDIAPI.DLL to v 3.0.1
   6/23/03  Updated TSEDIAPI.DLL to v 3.0.2
   1/03/04  Updated TSEDIAPI.DLL to v 3.1.0
   11/13/06 Updated TSEDIAPI.DLL to v 3.1.1
   09/03/07 Updated TSEDIAPI.DLL to v 3.1.2 
   05/22/09 updated              to v 3.2.1 (better error detection) 
   06/03/09 updated              to v 3.2.2 (added error literal, fixed another compiler-induced bug!) 
   08/20/09 updated              to v 3.2.3 (add test for length of segment file name when valid address passed)(only occurs with PPPS)
   11/08/11 updated              to v 3.2.4 (allow for spurious segment terms bewtween segments in TransSetSegmentArray routines).

USNCRYPT.DLL
   8/8/03   Added usncrypt.dll (product serializer)
   6.24.05   Updated usnCrypt.dll to version 1.5
   5.00.07   Now at version 1.8.0 
   ???? 
   7.31.12   usnCrypt 1.10.1 installed (EDEF Support) 


TSIUPGRADE.DLL
   1.04.06   Add tsiupgrade.dll version 1.0.2 for use with Inno Setup.
   3.15.06   tsiupgrade.dll V 1.1.0 (handles EDI Pal 23==>2.5, 2.5 update)
   8.16.05   tsiupgrade.dll v 1.2.0 (PPPS 3x upgrade support) (3.0 to 3.0)
   11.13.06  tsiupgrade.dll v 1.4.0 (had been in Utilities production for a while).
   05.11.07  tsiupgrade.dll v 1.7.0 
  


X096A1API.DLL, X096A1API.DLL and TSIIG022.DLL and TSIIG031.DLL parsers

    06.21.05  Added 837 API files X096A1API.DLL X098A1API.DLL TSIIG022.DLL TSIIG031.DLL
          versions 1.2.2 both APIs
    7.29.05   Updated X096A1API.DLL  to version 1.2.5 (bug fixes over 1.2.4)

    8.12.05   Add X096A1API.DLL version 2.0
    3.06.06   Changed tsiig031.dll (X098A1) to version 2.1.1

    03.19.07  Updated TSIIG022.DLL and TSIIG031.DLL to version 2.7.0 (not yet released to public) 
               Did this to test Microport Export stuff.
    08.15.07   Upgraded X096A1API.DLL  to 2.3.1
    08.15.07   Upgraded X098A1API.DLL  to 2.3.0
    05.19.08   Updgraded X098A1API.DLL to 2.3.1 
    02.26.09   Upgraded X096A1API.DLL  to 2.3.2 
    02.26.09   Upgraded X098A1API.DLL  to 2.3.2 
    05.01.09   Upgraded X098A1API.DLL  to 2.4.0 

    05.07.09   Upgraded X098A1API.DLL  to 2.4.1 
    05.07.09   Upgraded X096A1API.DLL  to 2.3.3 
    08.22.09   upgraded X098A1API.DLL  to 2.4.4 

PTREE32.DLL   PowerBASIC PowerTree RTL
    06.21.06  Add ptree32.dll v 1.10 (required by X096/X098A1API DLLs)


UNICOWS.DLL    MICROSOFT LAYER FOR UNICODE
     1.04.06   Add unicows.dll    version 1.0.3703 also for use with Inno Setup.


EGRIDPRO32.DLL
   02.06.07  Added EGRID32PRO.DLL v 3.28.4
   02.14.07  Updated EGRID32PRO.DLL to v 3.28.10
   12.01.11  updated EGRIDPRO.DLL to v 3.62.0

LIBHARU.DLL
 ** FILE DOES NOT HAVE A VERSION RESOURCE!!! **  (maybe I should try to add?) 
   02.26,09  Replaced whatever was here size 596K with 2.0.8 size 768 Kb 
 
WINMSG.DLL 
 02.18.10 copied from PBWIN90 install
DECLARE FUNCTION WindowMessage LIB "WINMSG.DLL" ALIAS "WindowMessageA" (BYVAL MsgNum AS LONG) AS STRING

TSI_LOGINORACLE.DLL
 10.22.13   Add this DLL version 1.0.1. 



// ENDS //

New DLL to test? Put it in here.

[Emanuele Colombo]

Hey Gary!
The way you suggested is the right one.
The problem is related to a dll built in the resource file (not scintilla, another one)
I copied the dll in the executable folder, and everything works fine.
Very strange problem.
I'm compiling with Win7 64bit. I have never encountered the same problem with Windows XP 32.
It may be that the PowerBASIC support (or Microsoft support) may clarify the issue?
In any case, you're right: it's easier to just repress.
Thank you very much!
(for this and all your gbStuff)

[Emanuele Colombo]

The problem seems to disappear by compiling the resource file as a PBR instead of as RES.

For MCM:

I had the problem with a pre-compiled RES file, in which my DLL is embedded in this way in to the RC file:
==> MYDLL RCDATA DISCARDABLE "MyPath\MyDll.DLL"
I think that the "source path" of the DLL is irrilevant, after compiling the RES file. I think tha I can delete the dll, since it is embedded in the RES.
But if I move the DLL from path, or If I rename the entire path, when I want to compile a program using my RES file, the "Resource File Error"
occour, (unfortunately randomly).
If I do the same using PBR format, with the SAME RC source file, all is OK.
Which resource format do you use?
Thank you very much for your help.

[Michael Mattias]

I mostly use PBR. Probably just an old habit. I'll probably use it until it no longer works anymore.

You may be having issues with RES if it's not the RES created by the PBRES program. When you create a PBR, there is actually a two-step process used by the IDE: RC ==> RES then RES==>PBR

Or, maybe have you have stuff in your RES not recognized by the current version of PB's RES==>PBR.

Or... I do know that when I want to put "\" in a file name in an RC, since "\" is an escape character I have to double it up...

Myrc.RC

MYDLL RCDATA DISCARDABLE "MyPath[U]\\[/U]MyDll.DLL"
...

Try that, see what happens.

MCM

[Cliff Nichols]

One thing over time that I have discovered is that if I am compiling on my USB stick it will randomly happen, but if the same stick is plugged into a USB1.0 hub it happens quite often, but if I copy everything to the hard drive and compile it NEVER happens.

I think its some sort of "Timeout" thing that if the resource is not written in a certain amount of time, then you get a resource error when really its just not done creating the resource yet?

[Emanuele Colombo]

I can rule out a problem with the file RES.
I compile the resource file with PBWIN 10, and the result
is the following:

Successfully created: C:\MyPath\MyFile.res
Successfully created: C:\MyPath\MyFile.pbr

Now, when I compile the main program, if I use:
#RESOURCE RES "C:\MyPath\MyFile.res"
I randomly get "resource file error".

If I use instead
#RESOURCE "C:\MyPath\MyFile.pbr"
the problem never happens.

May be that PWWin converts the RES file to PBR on the fly, but somethings
go wrong?

Thanks