Call DLL function not working.

bokkie · Post by **bokkie** » Mon May 11, 2009 6:59 am

Can anyone offer any explanation why my call to a dll function has stopped working? Here's the code:

~InstallAware Clipboard Data~
~Call DLL Function~
~{4FC59EEF-5733-4684-9415-BAFE3BF86997}~
~kernel32.dll,MoveFile,bool,MOVEFILESTATUS,"pointer to string",$TARGETDIR$\\ACE.Apollo.Framework.CacheSockets.dll,"pointer to string",$TARGETDIR$\\ACE.Apollo.Framework.CacheSockets.dll.PreP1BreakFix,$~
~mIDEFunc.dll\\mEXEFunc.dll~

I've got this call just before the ApplyInstall. The idea is that I make a copy of the existing file before the new one of the same name is installed. I set the MOVEFILESTATUS value to -999 before the call. After the call it still has the same value and the file is not renamed. I'm really convinced this used to work. I tried changing the bool return value to a long but no matter what I try now, the return value is still -999 (my initial setting) and it almost suggests that the call is not actually being made. I do have kernel32.dll in my XP Windows\\System32 folder.

All I'm trying to do is to rename the existing file before the new one is installed and I've got another call that renames the original file which is placed after the Apply Uninstall and that too fails to work. I can rename the files manually so I'm happy there's been no behind-the-scene access right restriction changes. I'm really puzzled. I know it has to be my fault but I'm totally flummoxed.

MichaelNesmith · Post by **MichaelNesmith** » Mon May 11, 2009 7:46 am

From MSDN:

Implemented as MoveFileW (Unicode) and MoveFileA (ANSI). Note that Unicode support on Windows Me/98/95 requires Microsoft Layer for Unicode.

You therefore have to use MoveFileA in the Function Name field in Call DLL Function.

bokkie · Post by **bokkie** » Mon May 11, 2009 8:33 am

Michael,

I tried that and it didn't work. I managed to make the intial copy by using the Move Local Files statement before the Apply Install. That worked. But trying to rename the original after the file has been renamed is where my next problem is. MoveFileA did not do it. I also tried using Move Local Files immediately before the Apply Uninstall statement. I'm probably missing the plot (yet again) but if I put my Move Local Files to rename the original file before Apply Uninstall, it would be sequenced as the last statement in the uninstall script? Is that correct? In other words, the file would be uninstalled and at some point in time, my Move Local Files as the last statement in should rename the original file? If so, it's not working and I've checked the pathnames so it looks ok.

bokkie · Post by **bokkie** » Mon May 11, 2009 11:20 am

Michael,

If you can comment on my questions above I'd appreciate that.

In the meantime, the same installations work fine on my Vista laptop at home. So, for some reason it seems that my XP machine got spooked today. I tried calling some other functions in kernel32 and they too failed to execute. Hopefully tomorrow's bootup will nail the problem. Darn it if I have not lost a lot of time today trying to get the installations to work. Now I know they do so. Interestingly, I have MoveFile in use and not MoveFileA. I will test this tomorrow and will confirm it. It looks like you should never underestimate the power of the On/Off button.

MichaelNesmith · Post by **MichaelNesmith** » Mon May 11, 2009 2:09 pm

I'm so sorry...apart from the obvious checks - such as ensuring the file to move exists, checking the return code, maybe getting a Win32 API result code, I don't have any other feedback

MichaelNesmith · Post by **MichaelNesmith** » Mon May 11, 2009 2:53 pm

Just had another idea - check DEP status - if its enabled for all programs, this might break the plug-in also...