Is Read equiv to WriteRegExpandStr available?

I'm trying to figure out how to invoke WordPad, which afaik isn't necessarily in the same place for older o/s.

In the registry, it is associated with .wri files, so that seems like a way to get the full path to its executable:

HKLM\SOFTWARE\Classes\SystemFileAssociations\.wri\open\command

However, this is of type REG_EXPAND_SZ, and I don't see how to use the equivalent of ReadRegExpandStr. Is this available somehow or other?

Is there a better way to do this? This seems pretty flawed.

ReadRegStr can handle REG_EXPAND_SZ. You can then use ExpandEnvStrings to expand the strings in it.

This seems to work ... but I'd appreciate feedback if this is a naive, flawed approach ... and whether there is a simpler, better solution.

I'm assuming that all o/s install WordPad. It first tries \App Paths\WORDPAD.EXE, and if not found, tries the SystemFileAssociations\.wri

(also, is there a "trim" or "left" function to remove any spaces at the end of a string? ... )

Var WordPadExePath

Var WordPadExePathLong

Var WordPadExeExpPath



Section /o "Try WordPad (provide both full path)"

  ExecWait '"$WordPadExeExpPath $INSTDIR\RtfExample.rtf"'

SectionEnd



Function .onInit

  ReadRegStr $WordPadExePath HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE" ""

  StrCmp $WordPadExePath "" TryWriAssociation WordPadExeResolved

  TryWriAssociation:

  ReadRegStr $WordPadExePathLong HKLM "SOFTWARE\Classes\SystemFileAssociations\.wri\shell\open\command" ""

  StrCpy $WordPadExePath $WordPadExePathLong -5 # Has "%1" at end

  WordPadExeResolved:

  ExpandEnvStrings $WordPadExeExpPath $WordPadExePath

FunctionEnd

Here is the code simplified:

ReadRegStr $WordPadExePath HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE" ""

 StrCmp $WordPadExePath "" 0 GotWordPadPath



  ReadRegStr $R1 HKLM "SOFTWARE\Classes\SystemFileAssociations\.wri\shell\open\command" ""

  StrCpy $WordPadExePath $R1 -5 # Has "%1" at end



GotWordPadPath:



ExpandEnvStrings $WordPadExePath $WordPadExePath

You really shouldn't create more global variables than necessary but use existing pre-defined variables where possible to save on memory on run-time. This now only uses $WordPadExePath.

Rather than remove the %1 off the end with StrCpy you could use this function which may be safer.
Also, this function removes leading and trailing white space from strings.

-Stu

ReadRegStr $WordPadExePath HKLM "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WORDPAD.EXE" ""

 StrCmp $WordPadExePath "" 0 +2

ReadRegStr $WordPadExePath HKLM "SOFTWARE\Classes\SystemFileAssociations\.wri\shell\open\command" ""



ExpandEnvStrings $WordPadExePath $WordPadExePath



Push $WordPadExePath

 Call GetInQuotes

Pop $WordPadExePath

This code uses GetInQuotes. You won't need to trim anything after using this.

-Stu

Thanks for the links.

You really shouldn't create more global variables than necessary but use existing pre-defined variables where possible to save on memory on run-time. This now only uses $WordPadExePath.

Not meaning to be unappreciative or argumentative, but I was curious how much difference this made. My tendency is to be VERY verbose, and the use of $0, $1, $R0, and $R1 has always struck me as very "old school" from the Fortran days.

Anyway, I did a "before" and "after". Memory usage of an application is hardly an "exact science", but my impression is that you can get a pretty good idea by watching the TaskManager while minimizing the app, then restoring it. This "strips" off the common dll's and is closer to your actual "working set".

Verbose: 36,692 bytes. Memory usage started at 1042kb and grew to 2960kb as the installer progressed (sections left unchecked)

Concise: 37,676 bytes. Memory usage started at 1048kb and grew to 2980kb as the installer progressed (sections left unchecked)

I would be the first to acknowledge that I am not at all an nsis expert, and these measurements may be naive or inaccurate (YMMV ... your milage may vary).

My tendency is to be VERY verbose, and the use of $0, $1, $R0, and $R1 has always struck me as very "old school" from the Fortran days.

What you can do is !define more verbose names for the default variables.
e.g.,

!define MY_DESCRIPTIVE_VARIABLE_NAME $R0

Then use ${DESCRIPTIVE_VARIABLE_NAME} whenever you need $R0

With the default options, each variable uses an extra 1KB of memory.

Just a small side remark Not all O/S need to have wordpad. In e.g .W98 You can select small install, or individually select NOT to install workpad. Ik know it is a little nitpicking fro my side but you asked, all OS's, the answer is no.

an alternative idea for you to create a filedisplayer with NSIS and have this in the temp folder to display your texts.

If your software is for an expected targetgoup of you it not so important, but as soon as your release software "in the wild" it is the best strategy NOT to relay on anything on the customers PC exept the basic OS.

A good way to test is to buy a old e.g. 300Mhz PIII with 64 MB PC and use this as sole test PC.

With e.g. Diskmagic put back the Clean OS fileimage of choice after every testruns.

A virtual machine is also possible but less representative.

Success.

Equivalent of Wordpad.exe in older versions of windows is Write.exe (hence the extension .wri), and IIRC it's been available since windows 3.0.

But I suggest you invoke "explorer.exe somedoc.wri" to open it, so leave it to windows shell to figure out how to open a file.