Hi all,

I have a weird situation. We have some Custom Actions that fire .exe's stored in the install package (Execute Program from Installation in the Wise Installation Studio world). On XP, we're good in that when the .exe's launch any forms or message boxes from the .exe, they are in front of Windows Installer or Installation dialogs.

During some testing on newer OSs --Win 7 and 2008 Server-- the .exe's fire, but their forms, message boxes, etc. are behind any displayed Windows Installer dialogs. It seems at that point that the installation is hung, because the user doesn't get direction from forms/messages that should be displaying.

What is causing this? Any workarounds? I even tried messing with the .exe's startup position settings, but that didn't change anything.

It's always something!!! [:'(]
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Have you tried adding the custom actions into the MSI directly using Orca instead of Wise?
Answered 12/08/2009 by: t_claydon
Senior Yellow Belt

Please log in to comment
0
No, but I'm curious as to what difference you might think that would make.
Answered 12/08/2009 by: Superfreak3
Black Belt

Please log in to comment
0
I'm guessing but this may be connected with modal/modeless dialog handling.

If the EXEs are yours, make sure the dialogs are modal. If they're not, I'm stumped, other than suggesting a major kludge, such as having the EXEs launched by a script which gets the handle of the app's window and forces it to the top of the Z order [shudder...]
Answered 12/09/2009 by: VBScab
Red Belt

Please log in to comment
0
Just speculation, but maybe wise has it's own code inserted into the MSI as a custom action that runs your customs action. Apart from that I would just use a process of elimination

Is there a problem with the way wise adds the custom action to the MSI?

Is there a problem with the way windows installer executes the custom action?

Is there a problem with the way the EXE are coded?

Can I fix the Code?

Can I find a work around?
Answered 12/09/2009 by: t_claydon
Senior Yellow Belt

Please log in to comment
0
maybe wise has it's own code inserted into the MSI as a custom action...thus making its MSIs totally incompatible with any other editor? I think not.Is there a problem with the way wise adds the custom action to the MSI? What other way do you imagine there is, than adding rows to the CustomAction and relevant execution tables?
Answered 12/09/2009 by: VBScab
Red Belt

Please log in to comment
0
...thus making its MSIs totally incompatible with any other editor? I think not....

Both Wise and InstallShield insert their own custom tables and custom actions into MSI's created by their products. This doesn't mean that MSI's are incompatible with other editors, in that they cannot be opened and edited it just means that if you open an MSI created by Wise with InstallShield, InstallShield doesn't know what to do with the custom tables or actions added by Wise.

In fact if you look at InstallShield, a lot of their MSI's require ISSCRIPT to be installed for the MSI to even install - Pretty non standard.

Anyway I was just speculating that maybe Wise inserted these "EXE's" into the MSI using the binary table and had it's own custom action the ran these "EXE's" and that I would check the MSI using Orca to make sure this wasn't the case before trying to get them recoded or find a work around. Considering the amount of junk both these products put into their MSI's, I don't think my suggestion was unreasonable.
Answered 12/09/2009 by: t_claydon
Senior Yellow Belt

Please log in to comment
0
Both Wise and InstallShield insert their own custom tables and custom actions into MSI's created by their products.....which they do by using standard MSI APIs. CAs are added to the CA table. Your original post implied that there was some magic way that Wise was adding CAs to the MSI and made no mention of custom tables. Quite what custom tables have to do with Custom Actions escapes me.In fact if you look at InstallShield, a lot of their MSI's require ISSCRIPT to be installed for the MSI to even install - Pretty non standard.So what? The requirement for ISSCRIPT is to execute function calls contained in the DLLs via Custom Actions - pretty standard.I was just speculating that maybe Wise inserted these "EXEs" into the MSI using the Binary table and had its own custom action the ran these "EXEs" How else would that work?!?
Answered 12/09/2009 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: Superfreak3

During some testing on newer OSs --Win 7 and 2008 Server-- the .exe's fire, but their forms, message boxes, etc. are behind any displayed Windows Installer dialogs.


Thinking of workarounds, do you really need to display the Windows Installer dialogs given that the EXE dialogs are themselves a visible indication that an installation is in progress ?

If the Windows Installer dialogs are prompting for user input, this can be avoided using an appropriate response transform.

Have you tried the installation using the available silent switches to msiexec.exe, (for example /qn) to see if that makes a difference ?

Spartacus
Answered 12/09/2009 by: spartacus
Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity