6 replies to this topic

[jenabe]

I have some install script that is grabbing a value off the property table and no matter what is there it always returns a null string...the property is one that I created called "REMOTESERVER" and is the name of the server upon which the database will be installed in a 3tier type deal...

PS - I go this code out of that new book by Bob Baker and changed it to suit my need.

nBUFFER = 10;
szPropertyValue = "";
MsiGetProperty (hMSI,"REMOTESERVER",szPropertyValue,nBUFFER);

//get the required buffer size and then resize  
nBUFFER = nBUFFER + 1;
Resize(szPropertyValue,nBUFFER);
MsiGetProperty (hMSI,"REMOTESERVER",szPropertyValue,nBUFFER);

help!!!!

[jenabe]

Oops...that initial value on nBUFFER is actually 0 in the code, not 10 as it is in the e-mail. My mistake when copying over.

I repeat...help :-)

[jenabe]

Wait...I think I have figured it out. The custom action that runs this baby is set to deferred execution...limited access to properties!!!

Phew...that only took me a couple of hours of banging my head against the cubicle wall to figure out :-)

[Scott Mayham]

I too am struggling with Custom Actions.  I need to capture the value of INSTALLDIR, for use by a CA after all the files in the package have been delivered.  

Literature (Bob Baker) indicates that this is among those properties which are NOT exposed that late in the process.  It would seem that I need to grab that value earlier, via MsiGetProperty, and save it somehow, via a Custom Action.  Then, using another CA, executed after the files are installed, I need to retrieve this saved value in order to use it.

Well, I tried.  The first CA (written in InstallScript)  correctly collected the value of INSTALLDIR.  This has been confirmed by use of MessageBox.  

This is where things get troublesome.  The CA then uses MsiSetProperty to save the retrieved value in the Property CustomActionData, seemingly with no errors.  However, when the second CA executes later, and attempts to pick up the value saved in CustomActionData (via MsiGetProperty), It is returned a null string.

What am I doing wrong?  Or, is my approach screwy?  Or, is there a way to get the value of INSTALLDIR after the files have been delivered, without having to save it in the Property table?  I'm stumped!

[Stefan Krueger]

There's an article in the InstalLShield knowledge base that should help you. Search for "deferred" in the title.

[Scott Mayham]

Thank you, Stefan.

Actually, I already knew about the deferred .vs. immediate issue.  In my post, the first CA, the one which grabbed the value and stashed it, was "immediate", and the other, which later used the stashed value, was "deferred".   So the problem seems to go deeper than that.

After perusing the wonderful world of MSDN, I noticed that in the discussion re:MSi*etProperty, there is some concern over the format of "string" type data passed via these methods.  That raised some concern in my own mind, since InstallScript (unlike, for example, VB) seems to give you no control over which of the several Windows string formats are used.  

However, while searching for an answer for that one, I returned to Bob Baker's book, and tried something I had previously avoided, the "type 51" CA.  (It is well named, being about as inscrutable and obscure as the famous Area 51 in Nevada - Sorry, Bob, your book helps, but it still isn't real clear).  Anyway, after several attempts and re-readings, I managed to get this technique to work.  

What I found to be confusing about Type 51 is that the thing you must designate as the "source" in the CA Wizard, is actually the name of the CA which is to receive the data, while the "target" is the name of the property whose value you which to pass.  They seemed reversed to me.  Also, it is not clear why the name of the receiving CA is critical - this technique would nod work until I designated the second CA's name as the "source", rather than the property name CustomActionData.

At any rate, I'm off and running once again.  Thanks again for your response.