Is Read equiv to WriteRegExpandStr available?

Archive: Is Read equiv to WriteRegExpandStr available?

l_d_allan
18th October 2005 18:26 UTC

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.

kichik
18th October 2005 21:14 UTC

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

l_d_allan
19th October 2005 14:06 UTC

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

Afrow UK
19th October 2005 14:23 UTC

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

Afrow UK
19th October 2005 14:27 UTC


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

l_d_allan
19th October 2005 16:02 UTC

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).

iceman_k
19th October 2005 17:09 UTC

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

kichik
20th October 2005 19:35 UTC

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

onad
25th October 2005 11:32 UTC

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.

nsismonk
25th October 2005 14:17 UTC

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.