I want to change property value to selected text in a dialog.
this is my sample source.
#include "ifx.h"
STRING outPath;
export prototype MyFunction(HWND);
function OnFirstUIBefore()
NUMBER nResult, nSetupType, nvSize, nUser;
STRING szTitle, szMsg, szQuestion, svName, svCompany, szFile, szDir;
STRING szLicenseFile;
BOOL bCustom, bIgnore1, bIgnore2;
begin
Dlg_SdAskDestPath:
nResult = SdAskDestPath(szTitle, szMsg, INSTALLDIR, 0);
if (nResult = BACK) goto Dlg_SdAskDestPath;
Dlg_AskOutPath:
nResult = AskDestPath(szTitle, szmsg, szDir, 0);
if (nResult = BACK) goto Dlg_SdAskDestPath;
outPath = szDir;
MyFunction(ISMSI_HANDLE);
return 0;
end;
function MyFunction(hMSI)
STRING value;
begin
MsiSetProperty(hMSI, "OutPutPath", outPath);
end;
OutPutPath used in custom action after finish install.
But OutPutPath was not changed when read in custom action.
I think I must not use ISMSI_HANDLE. But i don't know what i have to use instead.
I tried to make custom action which load Install scripts's method MyFunction after finish install.
It worked well, But the global variable outPath was nul..
Please teach me how can i do this if you know.
Thank you.
At a minimum, you must use a public property, that is one with a name that does not contain any lowercase letters. You may also have to list it in SecureCustomProperties in order to allow users to modify it, if you support installation in restricted environments.
However I'm not certain the exact scenario described by your comment:
I tried to make custom action which load Install scripts's method MyFunction after finish install.
If this scenario is truly after the end of the Windows Installer portion of the installation (an InstallScript MSI runs code both before and after), properties as a whole may not survive to do what you need. To support reading the value at that time you will have to consider other approaches, such as writing the value in the registry, or into a file (e.g. in SUPPORTDIR).
Related
I am trying to set up a MFC C++ App in Visual Studio 2019 such that modifies the user's text as they are typing.
Current layout is 2 radio buttons,
ID= rdbOn (set to Group = True, with Value int variable m_isOn = 1)
ID= rdbOff, m_isOn value would be = 0
and 1 Edit Control,
ID= txtInputBox, with Value CString variable m_inputString
Currently, for testing I can see how it would work for a button on click, it would take something like the following and just SetDlgItemText of the result. But that would be after they have typed, not WHILE they are typing.
void Onsomebtnclick()
{
//convert CString to String of m_inputString
//do some string manipulation
//convert back to CString
//SetDlgItemText(txtInputBox, result)
}
Update:
got EN_CHANGE to work
I was able to get EN_CHANGE working with the flag suggestion from user #GoGoWorx. However, now I just have a slight problem that the cursor is back to the beginning of the edit control txtInput.
I'm reading about using a CEdit::SetSel but don't know how to use that directly in my code. I tried
CEdit control MFC, placing cursor to end of string after SetWindowText
someDlg::someFunction()
{
//some logic stuff to get a result string
SetDlgItemText(txtInputBox, result);
//need it to set the cursor to the end
//I tried these, but it didn't recognize (expression must have class type?)
//txtInputBox.SetSel(0, -1);
//txtInputBox.SetSel(-1);
}
It sounds like you need to use the ON_EN_CHANGE message-map notification (called after the control has been updated due to typing or pasting for example)
BEGIN_MESSAGE_MAP(CMyDialog, CDialog)
ON_EN_CHANGE(IDC_EDIT_CONTROL, &CMyDialog::OnEnChangeEditControl)
END_MESSAGE_MAP()
void CMyDialog::OnEnChangeEditControl()
{
// Copy or call your Onsomebtnclick() here
}
I'm not sure what you're using for the numeric identifier for the edit control, since these are typically upper case defines - replace IDC_EDIT_CONTROL above with your define (possibly txtInputBox, but again, these are normally upper case, so I'm not sure).
Also change CMyDialog for the name of your dialog class too.
Note that we're using the ON_EN_CHANGE message-map handler here instead of the ON_EN_UPDATE, since the ON_EN_CHANGE message is sent after the control has been updated, whereas ON_EN_UPDATE is called just before it's updated.
The message-map handlers are described in the Remarks section of the CEdit control documentation: https://learn.microsoft.com/en-us/cpp/mfc/reference/cedit-class?view=msvc-160
Regarding your concern about modifying things as the user types - this should be fine, since every change (keystroke or paste from clipboard, etc.) should trigger this handler to be called, where you can change whatever you need. Just be sure that when you're updating the control, you don't trigger the ON_EN_CHANGE again and end up in a recursive 'change' loop.
You might be able to do this with some sort of flag to indicate you're the one updating the control, as opposed to the user, however it's probably better to subclass the CEdit control to do what you're wanting. There are a few examples out there of how to do this (it's not as difficult as it might sound), for example:
https://www.codeproject.com/Articles/27376/Avoiding-EN-CHANGE-notifications
I've just created a custom dialog with a checkbox asking if the user wants to create a desktop shortcut. I used to always include a shortcut I'm not using the AskText() function as I plan on adding more pieces to this page later and want to simplify these few options to this one page.
I get an item on my desktop when I run, but it's not what I expect. The target seems to be pointing to a location on the desktop itself and not the actual executable. Also, this shortcut does not delete on uninstall (I'm assuming this needs to be handled separately anyway) and the shortcut needs admin rights to be manually deleted (which I don't want, for obvious reasons).
Below is my InstallScript code. It is in a custom action that was inserted after InstallFiles.
function MyFunction(hMSI)
STRING szProgramFolder, szItemName, szCommandLine, szWorkingDir;
STRING szShortCutKey, szProgram, szParam, szIconPath;
NUMBER nIcon, nResult;
begin
szProgramFolder = FOLDER_DESKTOP;
szItemName = "myProgram";
szProgram = INSTALLDIR + "myProgram.exe" ;
LongPathToQuote (szProgram, TRUE);
szCommandLine = szProgram;
szWorkingDir = INSTALLDIR;
szIconPath = "";
nIcon = 0;
szShortCutKey = "";
nResult = AddFolderIcon (szProgramFolder, szItemName, szCommandLine,szWorkingDir,
szIconPath, nIcon, szShortCutKey, REPLACE);
end;
I'm not quite sure where I'm going wrong here, although my knowledge of InstallShield (let alone InstallScript) is very limited.
As it turned out, this is a deferred custom action, hence the INSTALLDIR variable is not initialized (nor any other Windows Installer built-in variables). Change it to an Immediate-type custom action (and relocate it to an appropriate location in the execution sequence) and it should work.
To fix the shortcut's parameters, start by ensuring they are correct. Debug your function to verify you are actually passing what you want to. As commented, INSTALLDIR may not be available directly to an InstallScript custom action. A simple way to "debug" would be to add calls like MessageBox(szCommandLine, 0); to key points in your code. If you find you are passing something like C:\Program Files\Company\ProductmyProgram.exe, consider using the ^ operator to concatenate your paths: szProgram = INSTALLDIR ^ "myProgram.exe";.
To uninstall the shortcut, you have to understand that custom actions in MSI projects are not automatically reversed. So use a different approach. Either explicitly code up its removal during uninstall in another action, switch to pure InstallScript where logging will reverse your actions, or go with a proper MSI-based approach. For the last of those, define the shortcut in its own component, and give the component a condition that correlates to a property you set in your UI (or via AskText for now), or skip the condition and just use feature selection by putting the component in a child feature. Then Windows Installer will track and remove the shortcut for you.
I'm working with Microsoft Excel via Delphi 7. It works fine but while formatting rows and ranges I have to write such long strings.
XLApp.Workbooks[1].WorkSheets[NameDoc].Range['A19:L19'].Font.Bold := true;
So I want to get rid of hard work and do it via "with..do" statement like this
with XLApp.Workbooks[1].WorkSheets[NameDoc] do
begin
Range['A19:L19'].Font.Bold := true;
end;
But at compilation stage I see this error
Record, object or class type required
on string - "with..do".
I creating Excel object this way
XLApp: Variant;
XLApp := CreateOleObject('Excel.Application');
I consider that with..do statement doesen't works with variant type variable, but I want to know whether I'm right or not? And if I'm right is there any workaround to make it work?
Variant can be anything or nothing at all - compiler doesn't know it and cannot know: it is so called "dynamically typed value". Since it does not know - it does not know if there would be any members (properties, methods) and if there would - what names would they have.
To get the benefits of strong compile-time typing - including using of with but not only - you have to use interface variables, those that are provided by TExcelApplication component and underlying unit having those values "statically typerd" - thus providing for Delphi compiler to know value types when compiling, in before running. There are plenty of types like iWorsksheet, iRange and others in that unit.
Borland Delphi 7 TExcelApplication.Connect works on office machines but not at client
http://www.delphipages.com/forum/showthread.php?t=157889
http://delphikingdom.ru/asp/viewitem.asp?catalogid=1270
However, since that is about reference-counting and lifetime I'd suggest you go with explicit use of temp variables rather than using with with and implicit invisible variables. Since you cannot control their lifespan and their clearance you might hit the wall in some unexpected place later. I did.
var tmpR: iRange; // assuming we have statically-typed API
// for example - providing we using ExcelXP or Excel2000 unit
tmpR := XLApp.Workbooks[1].WorkSheets[NameDoc];
tmpR.Range['A19:L19'].Font.Bold := true; // instead of with
with tmpR do // also possible but gives little benefit now
begin // when we made a dedicated temp var
Range['A19:L19'].Font.Bold := true;
end;
tmpR := nil; // crucial unless the most short and simplistic functions
// just release hold on Excel's object - let it manage its memory freely,
// by letting Excel know your program no more uses that object.
Also read
https://en.wikipedia.org/wiki/Automatic_Reference_Counting
https://en.wikipedia.org/wiki/Component_Object_Model
Can with be used with a Variant?
No.
You can use with for types whose members are known at compile time. But variants, for which the . operator is evaluated at run time, do not fall into this category. Hence with is not available for variants.
The documentation says, with my emphasis:
A with statement is a shorthand for referencing the fields of a record
or the fields, properties, and methods of an object. The syntax of a
with statement is:
with obj do statement
or:
with obj1, ..., objn do statement
where obj is an expression yielding a reference to a record, object
instance, class instance, interface or class type (metaclass)
instance, and statement is any simple or structured statement.
When my program attempts to generate an AFX_IDP_PARSE_REAL error for the user, it fails to load the string that is stored in the afxres.rc file. I found this question already, however it was solved because the reference to afxres.rc was accidentally deleted from the program.rc file. That is not the case for me. My program.rc file includes the exact code listed in the answer to include the afxres.rc file.
In debug mode, it breaks on the ASSERT below.
int AFXAPI AfxMessageBox(UINT nIDPrompt, UINT nType, UINT nIDHelp)
{
CString string;
if (!string.LoadString(nIDPrompt))
{
TRACE(traceAppMsg, 0, "Error: failed to load message box prompt string 0x%04x.\n", nIDPrompt);
ASSERT(FALSE);
}
if (nIDHelp == (UINT)-1)
nIDHelp = nIDPrompt;
return AfxMessageBox(string, nType, nIDHelp);
}
When I am actually running the application via the .exe, it simply generates an empty warning box since the AFX_IDP_PARSE_REAL string is not loaded; this goes for any string in the afxres.rc.
What could cause the application to not load the string from the afxres.rc?
Just letting you know that it is not enough to include the afxres.rc file normally, the way you include header files into cpp/h files. You actually need to include it twice. If you create a brand new MFC project and check the code of an rc file (using "View Code" option) you would notice that there is a normal include:
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "afxres.h"
and there is a TEXTINCLUDE section inside the rc file:
2 TEXTINCLUDE
BEGIN
"#include ""afxres.h""\r\n"
"\0"
END
You need to make sure you do the same thing in your project. Alternatively, you can use a "Resource Includes" wizard that is available via right click on the Resource View that allows editing the both sections via the dialog box:
I am using MsiGetProperty to get string parameter value from the installer.
And after that I am calling a managed dll and I pass the that value:
nvBufferSize = MAX_STRING;
MsiGetProperty (hMSI, "DBHMS", sDbHost, nvBufferSize);
when I pass the value of sDbHost is like this when I receive it from managed code:
srvdata-02NULNULNULNULNULNUL......
however in the interface I wrote just "srvdata-02".
With that same code it was fine with Installshield 2010, now I am upgrading it to installshield 2012.
Do you have any solution with that please?
There were some behavior changes to MsiGetProperty awhile back. Try setting nvBufferSize to MAX_SIZE instead of MAX_STRING. Also check the return code of MsiGetProperty to see if it equals ERROR_MORE_DATA or if it's returning some other code. Finally check the value of nvBufferSize to see how many bytes are needed.
BTW, if you are just trying to marshal a property over to managed code, you might want to conisder looking into Deployment Tools Framework (DTF) in Windows Installer XML (WiX). This is a very nice SDK that allows you to write managed code custom actions and package them up as if they are native Win32 libraries. InstallShield can then easily use this as an MSI DLL custom action.
DTF provides an interop library and a session object that can be used like:
Deployment Tools Foundation (DTF) Managed Custom Actions
Reasons DTF is Better
As ridiculous as it may seem, here's a working InstallScript solution for you:
nvBufferSize = MAX_STRING;
nResult = MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
if( nResult = ERROR_MORE_DATA ) then
MsiGetProperty( ISMSI_HANDLE, szPropertyName, svValue, nvBufferSize );
endif;
The first attempt returns the actual buffer size needed. If it is more then max string (1024?), the second call gets the whole thing.
Alternatively, I found I could assign nvBufferSize to larger value right off the bat e.g. 4096 and use that with a single call (assuming the data was no longer that limit). The double call, however, is more fool proof.
According to: https://msdn.microsoft.com/en-us/library/aa370134(v=vs.85).aspx the api function is actually designed to return the buffersize by passing an empty literal ("") instead of a string variable. InstallScript 2013 throws a compilation error at you if you try that though...