- NSIS Discussion
- LogEx plugin
Archive: LogEx plugin
jpderuiter
13th February 2007 01:43 UTC
LogEx plugin
I have created a new Logging plugin:
http://nsis.sourceforge.net/LogEx_plug-in
With this plugin you can:
- Open a new or existing logfile, and append strings to it.
- Copy this string to the Status Listbox and/or Statusbar. (like DetailPrint)
- Append an existing file to the log file (esp. usefull when executing a console app)
--- Add a prefix to each new line of this file.
--- Choose which lines from this file to append.
Example:
LogEx::Init /NOUNLOAD "$TEMP\log.txt"
LogEx::Write /NOUNLOAD "Write this line to the log file only"
LogEx::Write /NOUNLOAD "Write this line to the log file and the status list box" true
LogEx::Write /NOUNLOAD "Write this line to the log file, the status list box and \
the statusbar" true true
LogEx::Write /NOUNLOAD 'Write complete "dir" output to the log file with ">" as prefix'
ExecDos::exec 'cmd /C dir' "" "$TEMP\output.log"
LogEx::AddFile /NOUNLOAD "$TEMP\output.log" ">"
LogEx::Write /NOUNLOAD 'Write "dir" output from line3 to the log file'
ExecDos::exec 'cmd /C dir' "" "$TEMP\output.log"
LogEx::AddFile /NOUNLOAD "$TEMP\output.log" "" 3
LogEx::Write /NOUNLOAD 'Write "dir" output from line3 to line6 to the log file'
ExecDos::exec 'cmd /C dir' "" "$TEMP\output.log"
LogEx::AddFile /NOUNLOAD "$TEMP\output.log" "" 3 6
LogEx::Close
Please give your comments.
JP de Ruiter
palecekp
16th February 2007 11:44 UTC
stack problem
Hi,
I found your plugin for logging and try to use it.
There is a little bit problem with LogEx::Write function, which totaly destroy (clean) the stack (maybe more 'pops' then 'pushs').
I didn't tested another functions in library.
In other way, library looks very usefull.
Best regards Pavel Palecek
jpderuiter
16th February 2007 22:49 UTC
RE: stack problem
Hi,
Thanks for trying.:)
maybe more 'pops' then 'pushs'
you are right.
It did always read the max number of parameters, so when you specified less parameters then max, there where more pops then pushes. :rolleyes:
I did fix this (I changed the order of parameters: optional parameters first, and check if they are valid)
Also did the following:
v0.2
- Fixed stack bug.
- Added parameter "bAppendToFile" to Init function
- Changed the way AddFile function reads the file (read the file at ones in a buffer allocated with VirtualAlloc)
- Added comments in sourcecode
See the plugin page at http://nsis.sourceforge.net/LogEx_plug-in for version 0.2
Hope you can use this plugin.
JP
jpderuiter
17th February 2007 00:35 UTC
I found a small bug with v0.2
When the function AddFile was used with an empty file, the installer crashed.
I uploaded a new version: 0.3.
It checks the filesize, and if zero returns right away.
Best regards,
Jan Pieter
jpderuiter
18th February 2007 21:36 UTC
P.S.: the example in the first post doesn't work anymore.
See http://nsis.sourceforge.net/LogEx_plug-in for a valid example.
JP
palecekp
19th February 2007 08:14 UTC
Re: RE: stack problem
Hi,
plugin works very well, in my case, now.
Thank you
Pavel Palecek
djg72
30th March 2007 22:37 UTC
Problems with Append
I am trying to write a script using LogEx. It installs SQL Express and then reboots. I seem to only get log entries from after the reboot.
I tried using the bAppendToFile:
LogEx::Init /NOUNLOAD bAppendToFile "$INSTDIR\InstallLog.txt"
Which created a file named "bAppendToFile" on my desktop.
I also tried:
LogEx::Init /NOUNLOAD /bAppendToFile "$INSTDIR\InstallLog.txt"
Which didn't seem to create a file at all.
I may have my syntax wrong, could you post an example with the correct syntax for appending to a file?
Thanks.
jpderuiter
31st March 2007 13:14 UTC
Hello djg72,
thanks for trying this plugin!
You pointed my to a small error in the readme file:
In the readme file I talked about 'bAppendFile' , while I actually use 'bTruncateFile'. I fixed it now.
Thanks for that.
Now to your problem:
I used the so called 'Hungarian' variable namestyle.
This means that I added a 'b' in front of the variable name when it's a boolean variable.
So bTruncateFile is a boolean variable.
To use truncation (when the logfile already exist, all data will be erased), use the following code:
LogEx::Init /NOUNLOAD true "$INSTDIR\InstallLog.txt"
When you use the following code:
LogEx::Init /NOUNLOAD "$INSTDIR\InstallLog.txt"
and the logfile already exists, the existing data will not be deleted.
Hope this will help you.
Best regards,
Jan Pieter
djg72
2nd April 2007 18:40 UTC
Thanks
Thank you for your reply. I had originally tried using the line you suggested and it didn't work. Thank you also for clearing up that 'bTruncateFile' and 'bAppendFile' are the true and false of the same variable.
I figured out my problem was I tried to open the logfile in the .onInit function which was trying to write to a directory that didn't exist. Once rebooted, the directory existed and the logfile could be written.
I changed:
Function .onInit
;Open Log file
LogEx::Init /NOUNLOAD "$INSTDIR\InstallLog.txt"
LogEx::Write /NOUNLOAD "Function .onInit : Log File Opened..."
To this:
Function .onInit
;Open Log file
SetOutPath "$INSTDIR"
LogEx::Init /NOUNLOAD "$INSTDIR\InstallLog.txt"
LogEx::Write /NOUNLOAD "Function .onInit : Log File Opened..."
Maybe this will help someone.
Thanks again for your help and this plugin works great.
lushdog
27th August 2007 12:50 UTC
I'm getting a "ÿþ" when I try to append a few particular files to the log.
They are logs from the most recent version of MS SQL Express so I'm thinking it's an encoding issue (i.e. not plain text).
Any ideas?
jpderuiter
27th August 2007 12:56 UTC
Can you send me a log file?
I don't have SQL server installed right now.
Regards, JP
lushdog
27th August 2007 14:03 UTC
It's because the SQL server log uses UTF-Little Endian encoding rather than ASCII.
It works if I convert the logfile to asciI "c:\type unicode.txt > ascii.txt".
My only problem is that "type.exe" isn't anywhere on my windows install so I'm having problems running it with "exec" or with the "execdos" plugin.
jpderuiter
27th August 2007 14:22 UTC
It's 'part' of the command shell.
try: '$SYSDIR\cmd.exe /c "type unicode.txt > ascii.txt"'
lushdog
27th August 2007 14:24 UTC
Or:
ReadEnvStr $R0 COMSPEC
ExecWait '"$R0" /C TYPE "c:\summary.txt" > "c:\SummaryAscii.txt"'
Thanks a bunch!!!
jpderuiter
27th August 2007 14:27 UTC
Your welcome.
Thanks for using my plug-in.
fantrs91
25th April 2008 16:41 UTC
Hi,
I'm using your plugin and it's really helpful :)
I have one minor issue with it: when using logex::Close, the log file I generate gets 2 blank lines at the end.
Is there a way to avoid having blank lines at the end of the file ?
Thanks
jpderuiter
25th April 2008 23:34 UTC
Hi,
great to hear you like my plugin.
About your issue: I have never seen this.
All my generated log files end without extra lines.
Can you give me a piece of code with which I can reproduce this?
BTW, you mentioned that this happens when you use ::Close.
Does this mean that if you don't use ::Close, the logfile does not have these extra lines?
Best regards,
Jan Pieter
jpderuiter
26th April 2008 19:04 UTC
Hi,
I looked in it a little further, and I was able to reproduce your issue.
It turned out that I never closed the plugin properly in my own installer :rolleyes:
I fixed the plugin, so you shouldn't see this issue anymore with v0.4
(see http://nsis.sourceforge.net/LogEx_plug-in)
Thanks for pointing me to this :)
Regards,
Jan Pieter
fantrs91
28th April 2008 12:17 UTC
Hi,
You are right, I did not have the blank lines when NOT using logex::Close , with plugin version 0.3 .
I just downnloaded and installed version 0.4 and it now works perfectly :-)
Thanks a lot!
baxi
8th October 2008 15:16 UTC
Read right on the file
I tried your plugin and found it to be quite usefull. I have only one problem with it: the file cannot be read while it is opened via your plugin. I would suggest the to change the dwShareMode parameter in the CreateFile function at least to 1:
if(!strcmp(buf,"true"))
{
popstring(buf); // Get Second parameter from the stack (should be the log filename)
// Open an existing file and overwrite, or create a new file, without sharing
hFile=CreateFile(buf,FILE_WRITE_DATA,1,NULL,CREATE_ALWAYS,FILE_ATTRIBUTE_NORMAL
,NULL);
}// else open an existing file and append, or create a new file, without sharing
else hFile=CreateFile(buf,FILE_APPEND_DATA,1,NULL,OPEN_ALWAYS,FILE_ATTRIBUTE_NORMAL,N
ULL);
jpderuiter
8th October 2008 18:20 UTC
Hello baxi,
good suggestion.
I updated the plugin, you can find it here:
http://nsis.sourceforge.net/LogEx_plug-in
Can you please confirm that it's working, because I'm not able to test the plugin right now.
Regards,
JP
baxi
8th October 2008 18:35 UTC
Hi,
I tried it and its working fine
Baxi
jpderuiter
9th October 2008 17:17 UTC
Thanks for trying and letting me know.
I hope you find this plugin usefull
JP
knippenberg
28th November 2008 16:29 UTC
LogEx with NSIS Unicode branch
Hi JP,
I have been using your plugin for several weeks now and it worked fine so far. Just today I switched to the unicode build of nsis available at http://www.scratchpaper.com/, since we needed to support unicode languages in our installer. Since then, it seems that your plugin doesn't work any more. I copied the LogEx.dll to the new plugin subfolder and don't get any errors on compiling. When I run the installer, it creates a file named "t" in the installer's directory, and doesn't create any logfiles any more.
Any ideas on this? I think it may be due to the fact that the whole installer script is now provided as UTF8-encoded file rather than ANSI.
Thanks for your efforts,
Stefan
jpderuiter
28th November 2008 17:35 UTC
Hi Stefan,
since more people asked for Unicode support, I decided to implement it in the LogEx plugin.
(It turned out to to be quiet easy actually).
I updated the plugin, you can find it here:
http://nsis.sourceforge.net/LogEx_plug-in
I tried it with non-Unicode, and that works.
Can you please confirm that it's working for Unicode as well?
Regards,
JP
knippenberg
1st December 2008 10:49 UTC
Hi JP,
thanks for your quick response! In tried the update immediately (well... immediately as i read your post :)) but couldn't get it to work...
I still have the same issue with the "t" file in the setup.exe directory. When opening it with notepad, I can see that there are several lines with one character. It contains t's and f's, so my guess is that LogEx accidentally logs the calls to the LogEx routine itself.
I use it like this:
Section "Required components" SEC01
....
LogEx::Init /NOUNLOAD true "${INSTALL_LOGFILE}"
LogEx::Write /NOUNLOAD false false "logging started..."
The call to Init seems to create the "t" file, and all succeeding calls to Write seem to add one line with the letter t or f to the file, most probably depending on which parameters I use.
At the point of the init call, the directory for INSTALL_LOGFILE already exists.
Any idea what I'm doing wrong here?
Thanks,
Stefan
jpderuiter
1st December 2008 21:09 UTC
Hi Stefan,
OK, so appearantly it isn't that easy.
I installed the Unicode version, and got the same problems you have.
I'm not sure what the problem is, I haven't found it so far.
I'll let you know when I found the solution.
JP
jpderuiter
30th December 2008 12:24 UTC
Hi Stefan,
it took some longer than I thought, but I finally have made a (separate) Unicode plugin.
It is included in the zip file from http://nsis.sourceforge.net/LogEx_plug-in.
Hope you can still use it.
Best regards, JP
P.S.: Also used the new NSIS 2.42 API library with this version (0.7)
jpderuiter
31st December 2008 10:22 UTC
I uploaded v0.7.1, which now uses the PluginCallback function from the new NSIS API lib, so /NOUNLOAD is no longer required.
Regards,
JP
knippenberg
7th January 2009 08:51 UTC
Hi JP,
just noticed your post, I definetely can still use it and will try it asap. Thanks for your efforts!
Stefan
knippenberg
7th January 2009 11:06 UTC
Hi again,
I tested the new version but still have the same issue as before. I also tried with the provided example in the zip file:
converted to unicode,
compile (success),
execute (file t with singular character per row)
I went as far as deinstalling both the normal and the unicode version of nsis and installing a fresh 2.42 unicode version, so I won't accidentally use the wrong version. Still the same... I removed the /NOUNLOAD parameter as well.
For LogEx, I first just copied the dll in the unicode folder to the nsis plugin directory.
Also tried extracting everything in the zip to the nsis root dir, leaving me with one LogEx.dll in \Plugins and one LogEx.dll in Plugins\Unicode. Neither version works for me...
Any ideas?
Stefan
jpderuiter
7th January 2009 15:14 UTC
Hi Stefan,
Removing the /NOUNLOAD in the Unicode version appearantly doesn't work.
But when I use the /NOUNLOAD, the Unicode version works OK.
Can you try the attached Unicode example?
It isworking fine here.
I will ask jimpark about the /NOUNLOAD.
Regards, JP
jimpark
7th January 2009 19:48 UTC
I was able to make the LogEx plugin work simply by using the right pluginapi.lib. However, the DosEx plugin needs to be ported over also for the exampleu.nsi to work. :(
jpderuiter
7th January 2009 21:18 UTC
Hi Stefan,
I released a new version of the LogEx plugin, which in combination with the new NSIS 2.42 Unicode (not available yet) will work without the /NOUNLOAD.
Best regards, JP
P.S.: jimpark, you're right, I forgot to mention that the ExecDos plugin does not work with Unicode.
I used a logfile created with the non Unicode ExecDos plugin which I converted to Unicode manually.
knippenberg
8th January 2009 12:29 UTC
Hi JP,
using your latest plugin version, it works without any other changes :) Thanks for your and jimpark's efforts :)
silo5
23rd March 2009 12:58 UTC
Hi JP, I'm using your plugin, version 0.7.2, thank you.
Normally it works just fine, but it seems to leave dirt on the stack when the current page isn't InstallFiles.
My installer has just one single custom page and no standard pages. I want to add to the log file but not to the details window, because there is no details window!
LogEx::Write false "text" should work, but the stack is dirty afterwards.
Another issue that I'm having is that even after LogEx::Close the installer can't delete the logfile:
Delete $logfile
doesn't do anything (I verified that the $logfile holds the full path).
jpderuiter
23rd March 2009 19:09 UTC
Hi silo5,
as I'm on vacation right now, I'm not able to look into your problem.
But I'll have a look at it as soon as I can.
Regards,
JP
silo5
23rd March 2009 21:07 UTC
Enjoy your vacation!
jpderuiter
26th March 2009 23:47 UTC
Hi silo5,
thanks, I did enjoy my vacation indeed.
About your issues:
The first one is because of me being lazy: It only checks for a "true", and doesn't expect a "false".
In fact I expect that "false" is written to the logfile instead of "text"...
I will fix this in a new version, but for now you can use
LogEx::Write "text"
instead.
As no "true" is found, it assumes it's false.
When checking for your second issue, I found that the logfile is released as soon as Logex::Close is called.
(The logfile is locked indeed while the Logex plugin has it opened).
Also calling Delete $logfile afterwards removed the logfile from my system.
Can you give me a script in which this issue happens, so that I can reproduce it?
Regards JP
silo5
27th March 2009 08:27 UTC
Originally posted by jpderuiter
It only checks for a "true", and doesn't expect a "false"...
I will fix this in a new version
When you do, check also that if "text" starts with a number it is taken to be "true" instead of being "text". I have this comment in my notes from a while ago, I did not check if you've already fixed this issue in the latest version.
When checking for your second issue, ... Can you give me a script in which this issue happens
I'll try
- NSIS Discussion
- LogEx plugin
Archive: LogEx plugin
silo5
27th March 2009 09:21 UTC
JP, sorry but I can't give you a script to reproduce this issue. I have chopped down my installer script to a bare minimum that I thought would reproduce but it doesn't.
jpderuiter
27th March 2009 18:27 UTC
sorry but I can't give you a script to reproduce this issue. I have chopped down my installer script to a bare minimum that I thought would reproduce but it doesn't.
Hmm, then I'm sorry as well, because I can't reproduce this either, and as far as I can see, there is nothing wrong with the plugin code .
When you do, check also that if "text" starts with a number it is taken to be "true" instead of being "text". I have this comment in my notes from a while ago, I did not check if you've already fixed this issue in the latest version.
Hmmm, I'm not able to reproduce this as well.
Maybe you can provide a script for this?
By the way, what version of NSIS are you using, the normal or the Unicode version?
JP
silo5
29th March 2009 08:32 UTC
I'm using the standard version.
Possiby you've alaready fixed the number vs. true issue in a recent update, like I said, I had this issue marked in my notes from a previous version, then I upgraded the plugin.
jpderuiter
30th March 2009 10:11 UTC
Possiby you've already fixed the number vs. true issue in a recent update, like I said
Yes, you're right.
Appearently I fixed this when I made the Unicode version.
(Though I wasn't aware of this issue...)
I will upload a new version with the "only checks for a 'true' and doesn't expect a 'false'" issue fix later today.
Regards,
JP
jpderuiter
30th March 2009 21:17 UTC
I uploaded a new version of the LogEx plugin, with the fix for "false" as a value for a boolean parameter.
http://nsis.sourceforge.net/LogEx_plug-in
silo5
1st April 2009 08:16 UTC
Thank you JP, tested here and it works fine.
I really appreciate your work.
FYI, to simplify my installer I rely on an undocumented behavior of your plugin. I call LogEx::Close even if the logfile hasn't been opened. Apparently this call is harmless and leaves the stack in good shape.
jpderuiter
1st April 2009 17:38 UTC
Hi silo5,
thanks for your feedback.
What do you mean with an "undocumented behavior of your plugin"?
Do you use it to deal with the problem that you can't delete the log file after closing the plugin?
Using LogEx::Close without a previous LogEx::Init won't do anything, since the LogEx::Close function does not find a logfile handle, and thus skips the Close call.
Please note that you need a LogEx::Close call after calling LogEx::Init, even if you didn't write anything to the logfile at all, because the Init function creates and opens the logfile.
Regards,
JP
silo5
2nd April 2009 14:06 UTC
Originally posted by jpderuiter
What do you mean with an "undocumented behavior of your plugin"?
That you had not explicitly said that is it OK to call LogEx::Close without a previous LogEx::Init. But now you have said it, so this behavior isn't undocumented anymore.
Do you use it to deal with the problem that you can't delete the log file after closing the plugin?
No, I worked around that problem in my code.
jpderuiter
2nd April 2009 18:30 UTC
That you had not explicitly said that is it OK to call LogEx::Close without a previous LogEx::Init.
Well, since it's good programming practice to check variables and stack before continuing a function, I don't think I should document this behaviour.
What to document when a function doesn't do anything at all anyway?
And what purpose has this behaviour for you?
Why do you do this at all?
silo5
3rd April 2009 13:20 UTC
It simplifies the code of my installer by keeping fewer state variables and writing less conditional code. I can't give a general example, because this simplification is specific to my installer code.
jpderuiter
3rd April 2009 13:33 UTC
OK, so I guess you only open a logfile when it's needed, but you don't want to check whether you opened the logfile before at the end of the script, so you always close the logfile.
Well, you can do that indeed, as explained before.
matthiasb
25th August 2010 11:01 UTC
I'm not entirely sure if it's a bug, wrong usage or caused by something different but calling LogEx::Write crashes the installer when using long strings.
Everything works as expected as long given string does not exceed 999 chars.
When trying to log a string with 1000 chars (1023 should be possible?) my application crashes.
Can someone confirm this?
jpderuiter
25th August 2010 12:23 UTC
Hi Matthias,
this is a bug indeed.
I assigned a TCHAR size of 1000, thinking that would be enough...
I will fix the plugin as soon as possible, but since I'm on vacation, this will be half september...
You can fix it yourself if you need it sooner, but then you'll have to recompile the plugin.
Change "TCHAR buf[1000];" to "TCHAR buf[NSIS_MAX_STRLEN];" in the Write function (line 146).
Sorry for the inconvenience.
jpderuiter
matthiasb
25th August 2010 12:54 UTC
Thanks for the fast response.
Since i have to log the stdout of an application untrimmed i'm going to use redirection instead for this one.
For everything else LogEx is fine as it is now.
Afrow UK
25th August 2010 15:58 UTC
@jpderuiter You should ideally be using the string_size plug-in function variable and not a compile time define (so people can use the 8192 string build without recompiling). You would also have to allocate the memory using GlobalAlloc.
Stu
jpderuiter
25th August 2010 22:05 UTC
Thanks, will do that.
gringoloco023
5th September 2010 14:26 UTC
using the string_size plug-in function variable ?
Would this be the right-way of using the string_size plug-in function variable:
TCHAR
*buf=GlobalAlloc(GPTR,string_size*sizeof(TCHAR));
instead of:
TCHARbuf
***91;NSIS_MAX_STRLEN***93;;
Afrow UK
5th September 2010 18:16 UTC
Just missing the cast:
TCHAR* buf = (TCHAR*)GlobalAlloc(GPTR, string_size * sizeof(TCHAR));
You could also use PTCHAR instead of TCHAR* which I always use nowadays. Note I also use TCHAR* buf as opposed to TCHAR *buf. Having the * next to the type as opposed to the variable name to me just makes more sense. Also don't forget GlobalFree.
Stu
jpderuiter
7th September 2010 20:02 UTC
Hi all,
unfortunately I'm getting a bunch of winntl.h compile errors.
This is the first time I see these errors, and I have no clue what's causing it.
Maybe something is wrong in the platform SDK, so maybe I'll have to reinstall everything.
But I do not have the spare time to do that...
Maybe somebody else can recompile it?
All that need to be changed is mentioned in the previous posts.
Thanks in advance.
jpderuiter
Afrow UK
7th September 2010 20:22 UTC
What are the errors?
When I'm building there are a couple of things:
1. Linker -> Input -> Ignore All Default Libraries
Set to Yes. Removes linkage to CRT (but does not remove dependency; see 2).
2. Linker -> Manifest File -> Generate Manifest
Set to Disabled otherwise your DLL will have a run time error if the required Microsoft Visual C Run Time library isn't installed (even though you're not using it).
3. C/C++ -> Code Generation -> Buffer Security Check
Set to No if you get "unresolved external symbol __security_cookie" link errors.
4. C/C++ -> Optimization -> Optimization
Set to Disabled if you get "unresolved external symbol _memset" link errors.
Stu
jpderuiter
7th September 2010 20:42 UTC
I'm building on VC6, so not all settings are available.
Changing the ones I can doesn't fix it.
This is part of the errorlog:
NOTE: WINVER has been defined as 0x0500 or greater which enables
Windows NT 5.0 and Windows 98 features. When these headers were released,
Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the current versions.
For this release when WINVER is defined as 0x0500 or greater, you can only
build beta or test applications. To build a retail application,
set WINVER to 0x0400 or visit http://www.microsoft.com/msdn/sdk
to see if retail Windows NT 5.0 or Windows 98 headers are available.
See the SDK release notes for more information.
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1050) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1051) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1052) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1061) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1062) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1063) : error C2081: 'LONG_PTR' : name in formal parameter list illegal
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1217) : error C2146: syntax error : missing ')' before identifier 'UINT'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1217) : error C2491: 'IsValidCodePage' : definition of dllimport function not allowed
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1217) : error C2059: syntax error : ')'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1217) : error C2085: 'CodePage' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1222) : error C2085: 'GetACP' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1227) : error C2085: 'GetOEMCP' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1233) : error C2146: syntax error : missing ')' before identifier 'UINT'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1233) : error C2085: 'GetCPInfo' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1233) : error C2146: syntax error : missing ',' before identifier 'UINT'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1233) : error C2146: syntax error : missing ',' before identifier 'CodePage'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1234) : error C2085: '__out' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1234) : error C2146: syntax error : missing ',' before identifier 'LPCPINFO'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1234) : error C2146: syntax error : missing ',' before identifier 'lpCPInfo'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1234) : error C2059: syntax error : ')'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1240) : error C2146: syntax error : missing ')' before identifier 'UINT'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1240) : error C2085: 'GetCPInfoExA' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1240) : error C2146: syntax error : missing ',' before identifier 'UINT'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1240) : error C2146: syntax error : missing ',' before identifier 'CodePage'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1241) : warning C4042: '__in' : has bad storage class
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1241) : error C2146: syntax error : missing ',' before identifier 'DWORD'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1241) : error C2146: syntax error : missing ',' before identifier 'dwFlags'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1242) : error C2085: '__out' : not in formal parameter list
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1242) : error C2146: syntax error : missing ',' before identifier 'LPCPINFOEXA'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1242) : error C2146: syntax error : missing ',' before identifier 'lpCPInfoEx'
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1242) : error C2059: syntax error : ')'
...
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include\winnls.h(1312) : fatal error C1003: error count exceeds 100; stopping compilation
Afrow UK
7th September 2010 20:46 UTC
Maybe the file is damaged? You could try reinstalling or upgrading.
Stu
steinbohrer
8th February 2011 00:21 UTC
NULL-char at the end of each line
Hi jpderuiter,
I've just tried your LogEx-plugin and there is one minor flaw.
I use your Unicode version and there is an NULL-char at the end of each line in the log-file.
LogEx::Init false "$EXEDIR\InstallLog.txt"
LogEx::Write true true "<> Dies ist ein äöüÄÖÜß LogEintrag!"
LogEx::Close
Please have a look at the picture:
http://www.procolab.at/LogEx.jpg
If I'm correct, the plugin is written in C and C uses ASCIIZ-strings.
Do you strip the end-marker off the string before you copy it to the log-file?
Is there any chance you can fix this in the near future? :)
Thank you very much,
Michael.
jpderuiter
8th February 2011 18:43 UTC
Fortunately I suddenly saw the light, and found that I had to put the SDK include Library at the top of the list of include directories in vs6.0.
Anyway, I compiled a new version of this plugin, check the wiki:
http://nsis.sourceforge.net/LogEx_plug-in
I fixed both bugs, the one from matthiasb (mentioned 25th august 2010) and the one from steinbohrer.
I don't have time to test it thoroughly, so if you find any problems, please tell me.
jpderuiter
hnedka
1st June 2011 03:18 UTC
Hi, I have probably discovered a bug. In function Log::Write, you don't remove the parameter from the stack if the file handle is not correct, which leads to stack corruption. May be present in other places, haven't checked.
jpderuiter
20th June 2011 20:01 UTC
Hi hnedka,
thanks for pointing that out.
I fixed it, and uploaded v0.9.1 to the wiki page.
SJSJ
18th August 2011 06:19 UTC
Timestamps in Logs?
Hi, a very useful plugin!
Is there a way to embed the timestamps when I do a LogEx::Write?
jpderuiter
18th August 2011 09:26 UTC
Hi,
not via the LogEx plugin, but you can get the current time with the Time plugin (http://nsis.sourceforge.net/Time_plug-in), or using the system plugin (http://stackoverflow.com/questions/2...ame-using-nsis).
absalom0
20th September 2011 18:41 UTC
I am currently doing development to test out support for Windows 8 (Windows Developer Preview). Is there any chance that LogEx will be updated to support Windows 8 (Windows version 6.2.8102) anytime soon? :)
Thanks
jpderuiter
21st September 2011 07:26 UTC
I'm not sure what you mean.
Is the LogEx plugin not working on Windows 8?
absalom0
21st September 2011 17:56 UTC
Yeah, I had plugins and forums confused. You're good. I am apparently looking at the wrong place. ><
Thanks though.
JoeSnuffie
6th July 2012 16:50 UTC
Prepend?
I'm using NSIS as a software updater for my company's applications. I am currently using an application called at the end of the NSIS application to create a log file but I would like to include this process in the NSIS application. To do this I need to be able to prepend my strings rather than append them. This will keep the latest update information at the top of the file. Can this be done?
jpderuiter
11th July 2012 22:03 UTC
Hi Joe,
no, you cannot prepend text to an existing logfile.
What you can do is create a new logfile when the installer starts, and when finished append the previous created logfile.
jpderuiter