You are here

Custom.nsh & !addpluginsdir

4 posts / 0 new
Last post
Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 days ago
DeveloperModerator
Joined: 2008-07-24 18:46
Custom.nsh & !addpluginsdir

I'm in the process of updating Listary Portable, and have run into a snag, due to a change in the format settings are being saved in.

Settings are now being saved in JSON format, and I'm using the nsJSON plugin to handle the file, to be able to change specific values in the file. I've previously tried doing ConfigWrite/ConfigRead, but the app doesn't like the modified file, hence why I'm trying to read/write from the file "properly".

The problem I've encountered, is that there doesn't seem to be any way to add a plugin dll in Custom.nsh so that can be called later on in a different segment.

Here's my Custom.nsh.

Note that this is only my most recent attempt at getting the plugin recognized, and it's still not working. Not sure what to try next.

Also, if this can't be figured out, I'm ok with releasing the app without it for now, although it won't have the disabling of auto-update checking implemented.

Aluísio A. S. G.
Offline
Last seen: 8 years 4 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
Anywhere

Just put a call to !addpluginsdir anywhere in the file (the path should be something like ${PACKAGE}\Other\Source).
That works for me, at least.

Previously known as kAlug.

Gord Caswell
Gord Caswell's picture
Offline
Last seen: 1 week 2 days ago
DeveloperModerator
Joined: 2008-07-24 18:46
${PACKAGE}

Ah, it was the ${PACKAGE} variable. I had tried with EXEDIR and wasn't getting anywhere, hence why I tried oninit as above. I'll be sending this to John for posting.

Chris Morgan
Chris Morgan's picture
Offline
Last seen: 9 years 5 months ago
Joined: 2007-04-15 21:08
Near the top

I would put the !addpluginsdir immediately after the ${SegmentFile}, but so long as it's before the use of the plugin, it doesn't matter. Also, your .onInit hook shouldn't be necessary at all. It could also be more efficient to put /NOUNLOAD on all the nsJSON::X calls except for the last one (it used to unload plugins each time unless this was specified, not sure if that's still the behvaiour employed). However it is, make sure that the plugin is not left behind

I am a Christian and a developer and moderator here.

“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1

Log in or register to post comments