7 replies to this topic

[biatche]

When PE boots up, I get

[b]RunBgInfo[/b]





! Could not copy image to SysWOW64. BgInfo will not be able to display your background image.

and after that info displays in background.

Running %ProgramFiles%\BGInfo\RunBGinfo.exe does the exact same thing


Yeah how do I fix this?

[sbaeder]

What if you try to execute bginfo directly? The "runBgInfo.exe" is a "shim" to make it wait until the network has started ...it is autoit, and it is in the attachments (source) folder...

You also didn't say what OS, etc. you are using? And did you download latest bginfo? a log file of the build may also help...

I can get same thing on an X64 system..have a wallpaper existing, so for me, it just starts bginfo...If I run RunBginfo a second time , I get this same error...

So, looking at the AU3 file, I see this error only happens on a 64 bit system, and it happens when trying to copy the "wallpaper" file to the sysWOW64. It looks like it does this so that BGINFO can see the original wall paper and do it's overlay on top of it...But that isn't working right anyway (I think it is a known issue on X64)...in any case,the popup he Autoit script can make a copy ...Probably because the file doesn't exist in the same way as before...(or no wall paper exists?)

need to play a bit more here...

[sbaeder]

I think I found a logic flaw...But I'm not 100% sure...

For me, on the PE, it works OK - BUT ONLY IF the wall paper has not already been screwed around with by BGinfo - OR - there is a valid wall paper set!

The file copy command isn't really checking to see if the file exists! So that is easy enough to add to the check on if the AU3 file should do the copy.

So, my guess is that you didn't have any wall paper set - right. It worked the first time for me, since I had one (and it copied it), but then the wall paper was set to the "temp one" that the RunBGInfo tries to delete. SO, when run the second time, it fails as you described.

This is because while the RunBGInfo has code to write to the INI the name of the current wall paper, and to check the INI file where it saves this, at the start of the program, it deletes any temp files (i.e. both the BMP from BGINFO and also the INI file it has created).

So *IF* the current wallpaper was in fact that temp one that BGINFO had created, it can't know this, since it has just deleted the ini file and as far as I can tell, the code to check if RunBGInfo has already saved the settings will never get called - it always updates the settings, and doesn't intelligently delete things

So, seems we should only try to copy the file *IF* it exists. But maybe we we should be smarter on the delete of the temp BMP in the first place - i.e. only remove the wall paper if it is NOT the current one...BUT, on top of all this, BGInfo still has the issue of it can only read a BMP...and not the "transcoded jpg" that is more normal for the wallpaper on Win7

So, as a short term "fix", I just added code to check if the wallpaper file "exists" before we try to copy it, but maybe we also need to worry about when we delete any existing temp ini file (and BGINFO.BMP file...Maybe homes32 can chime in here too...

In any case, this "fixes" the issue for me on multiple runs of the tool...and should work for you too...

Scott

Try updating the EXE in the x64 folder to see if this works for you...

Attached Files

•  BGInfo.zip   346.29KB   3 downloads

Edited by sbaeder, 28 October 2011 - 10:02 PM.
more info and zip attached

[biatche]

i have wallpaper script set to no wallpaper
i use win7 sp1 x64 as source
and yes thanks, your explanation makes sense and i assume its a bug.

thanks!

Edited by biatche, 28 October 2011 - 09:40 PM.

[sbaeder]

ee previous post - and yes, if NO wallpaper, then can't copy it!

[homes32]

The file copy command isn't really checking to see if the file exists! So that is easy enough to add to the check on if the AU3 file should do the copy.

that was intentional as the autoit FileCopy command will return 0 if there is an error or the file doesn't exist. either way I wanted the user to be notified that something was amiss...but I did not take into consideration no background wallpaper being available. So I accept the correction.

So, as a short term "fix", I just added code to check if the wallpaper file "exists" before we try to copy it, but maybe we also need to worry about when we delete any existing temp ini file (and BGINFO.BMP file...Maybe homes32 can chime in here too...

main reason for always dumping the temp file is that liveXP would sometimes have issues with writing txt on top of the old txt when it "refreshed"
I don't remember adding the ini delete though... it shoulden't be there because otherwise settings don't get read unless you are in refresh mode.
I'll play around a bit and see if I can't get something better working.

some history:

original reason for having Bginfo.ini is for the "customize' button on the script interface. by default bginfo applys the background when you are done editing and hit the "OK" button. this is not desirable as we don't want the bginfo displayed on our build PC but rather the PE! by saving the settings before run and applying them again after bginfo editing is complete we avoid this!

later the save/apply was extended to be run in PE as well as LiveXP was having issues where it would write over the previous txt and you would have 2 different "info" on your wallpaper.

[sbaeder]

@home32 - thanks for the history - I had guessed most of it. I think it is also necessary to have the ini file for the "refresh" mode inside the PE, since I think you do have to reset the registry variables so BGInfo will re-apply the information to the original background (again, assuming there is one)...

I think for now, it is work-able - i.e. able to work around and cope with current behavior while we think of better ways to do it...

THANKS again,


Scott

[homes32]

@home32 - thanks for the history - I had guessed most of it. I think it is also necessary to have the ini file for the "refresh" mode inside the PE, since I think you do have to reset the registry variables so BGInfo will re-apply the information to the original background (again, assuming there is one)...

I think for now, it is work-able - i.e. able to work around and cope with current behavior while we think of better ways to do it...

THANKS again,


Scott

I spent some time working on the code and think I may have something. I'll send you the exe for testing tonight if I get the time.