This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: CtrlGetText .Net Call Problem
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Mar 18, 2008
11:31 AM
CtrlGetText .Net Call Problem
Hello,
I have a problem when I use the String from a CtrlGetText-Function in the call of my .net DLL. Here's the code:
Setup.rul:
DlgConfiguration.rul:
When I use the Variable "szDeployPath" filled by the CtrlGetText Action, my DLL writes the following to my manifest file (the DLL is used to write text in a deployment-manifest file [clickonce]):
When I set the Variable myself before the call of the function:
...all works fine. When I use an .exe file instead of my .net DLL with the same code and call it in the command-line -> all works fine. So the .net code should be fine...anyway heres the code of my .net dll:
I've also tried to parse the variable with ParsePath ( szDeployPath, szDeployPath, PATH ); -> the same problem...
When I look at the szDeployPath-Variable, first filled with CtrlGetText, second setted by myself, I don't see any differences:
Sorry, a lot of text:) But i'm getting crazy on this issue, I hope someone can help me...
Kind regards,
Peter
I have a problem when I use the String from a CtrlGetText-Function in the call of my .net DLL. Here's the code:
Setup.rul:
//Includes
#include "DlgCertificate.rul"
...
//Global variables
STRING szDeployPath;
...
function OnInstallFilesActionAfter()
OBJECT oObj;
begin
szDeploymentManifest = INSTALLDIR + "\xxx.application";
szApplicationManifest = INSTALLDIR + "\xxx_xx_xx_xx_xx\xxx.manifest";
szApplicationManifestPath = INSTALLDIR + "\xxx_xx_xx_xx_xx";
set oObj = DotNetCoCreateObject(SUPPORTDIR ^ "InstallationSupport.dll", "InstallationSupport","");
oObj.setDeploymentUrlDeploymentManifest(szDeploymentManifest, szDeployPath);
end;
...
DlgConfiguration.rul:
//Defines
#define EDIT_DEPLOY_PATH 304
...
CtrlGetText(DLG_CONFIGURATION_DIALOG, EDIT_DEPLOY_PATH, szDeployPath);
...
When I use the Variable "szDeployPath" filled by the CtrlGetText Action, my DLL writes the following to my manifest file (the DLL is used to write text in a deployment-manifest file [clickonce]):
When I set the Variable myself before the call of the function:
szDeployPath = "\\\\deploymentServer\\test";
oObj.setDeploymentUrlDeploymentManifest(szDeploymentManifest, szDeployPath);
...all works fine. When I use an .exe file instead of my .net DLL with the same code and call it in the command-line -> all works fine. So the .net code should be fine...anyway heres the code of my .net dll:
using System;
using System.IO;
using Microsoft.Build.Tasks.Deployment.ManifestUtilities;
using System.Security.Cryptography.X509Certificates;
///
/// Summary description for clickOnceActions
///
public class InstallationSupport
{
public void setDeploymentUrlDeploymentManifest(string deploymentManifest, string newDeploymentUrl)
{
// Open the deployment file (.application)
DeployManifest deployManifest = ManifestReader.ReadManifest(deploymentManifest, false) as DeployManifest;
// Set the URL to the new url:
deployManifest.DeploymentUrl = newDeploymentUrl;
// Create a new manifest file
ManifestWriter.WriteManifest(deployManifest, deploymentManifest);
return newDeploymentUrl;
}
...
}
I've also tried to parse the variable with ParsePath ( szDeployPath, szDeployPath, PATH ); -> the same problem...
When I look at the szDeployPath-Variable, first filled with CtrlGetText, second setted by myself, I don't see any differences:
MessageBox("CtrlGetText: " + szDeployPath, INFORMATION);
szDeployPath = "\\\\deploymentServer\\test";
MessageBox("Self setted: " + szDeployPath, INFORMATION);
Sorry, a lot of text:) But i'm getting crazy on this issue, I hope someone can help me...
Kind regards,
Peter
(7) Replies
‎Mar 18, 2008
11:39 AM
One possible starting point; in your first block of code, where you have:
INSTALLDIR + "\xxx.application";
perhaps use this instead (^ instead of +, no leading backslash):
INSTALLDIR ^ "xxx.application";
INSTALLDIR + "\xxx.application";
perhaps use this instead (^ instead of +, no leading backslash):
INSTALLDIR ^ "xxx.application";
‎Mar 18, 2008
12:18 PM
RobertDickau wrote:
One possible starting point; in your first block of code, where you have:
INSTALLDIR + "\xxx.application";
perhaps use this instead (^ instead of +, no leading backslash):
INSTALLDIR ^ "xxx.application";
thanks for the quick answer...i've tried this:
szDeploymentManifest = INSTALLDIR ^ "\Ch.ZeitAg.System7.Client.Smart.application";
-> the same problem...I think the problem is szDeployPath, not the other variable (path to the file)
😞
Kind regards,
Peter
‎Mar 19, 2008
09:44 AM
short update:
I've stored my string "\\\\deploymentServer\\system7" in a msi property (CUSTOM_DEPLOY_PATH) and get it into szDeployPath before my .net Call:
-> the same problem...
😞
Any other ideas to solve my problem?
Kind regards,
Peter
I've stored my string "\\\\deploymentServer\\system7" in a msi property (CUSTOM_DEPLOY_PATH) and get it into szDeployPath before my .net Call:
MsiGetProperty(ISMSI_HANDLE, "CUSTOM_DEPLOY_PATH", szDeployPath, nLength);
oObj.setDeploymentUrlDeploymentManifest(szDeploymentManifest, szDeployPath);
-> the same problem...
😞
Any other ideas to solve my problem?
Kind regards,
Peter
‎Mar 20, 2008
09:33 AM
Hello,
sorry for my third reply here, but I need a solution for this. Does anyone has another idea where the problem could be located? What should I try?
Kind regards,
Peter
sorry for my third reply here, but I need a solution for this. Does anyone has another idea where the problem could be located? What should I try?
Kind regards,
Peter
‎Mar 24, 2008
06:05 PM
The C# strings might maintain the \0 padding from the InstallScript strings; perhaps use String.Remove in the .NET code to remove the padding?
‎May 17, 2008
09:17 AM
Thanks, I will try this...
Kind regards,
Peter
Kind regards,
Peter