SlickEdit Product Discussion > SlickEdit®

is the plugin mechanism useable in 25.0.2

<< < (4/5) > >>

I tried making the bitmap path a normal pathname but it didn't help.

// is copied to when packaging the xretrace plugin

//#define XRETRACE_PATH "plugin://user_graeme_nz.xretrace/"

#define XRETRACE_PATH _ConfigPath() :+ "/plugins/user_graeme_nz.xretrace/"


Ok, I do see this with the plugin you posted, with a clean config.  I'll quit SlickEdit, restart, and I don't see the bitmaps in the gutter.  Showing the xretrace options shows everything I selected is still selected.  Loading the module makes the bitmaps appear for that session, till I quit again.  And I get the say() output, so I know the init function is being called.

I'll see if I can trace why this is happening. 

I've tried fiddling with the definit and on-load-module code to see if I can see what is the difference between a manual load and a restart - but I got nowhere.  If I comment out some of the code, a manual load still makes the bitmaps work.  I did notice that after a manual load, on the next restart, the bitmaps work but not on the restart after that.

I've found another way to get the bitmaps working is to disable xretrace (using the config dialog), then restart xretrace by running the xretrace-cursor-steps command.  - it calls init-xretrace.  So it seems that init-xretrace works sometimes and sometimes not.  I  don't normally have bitmaps showing so I can't really tell whether this problem is because it's a plugin or because it sometimes happens anyway.  In my "normal" 25.0.2 config the bitmaps always appear so far.

I don't think you can do anything that isn't extremely hacky to work around this.  I've gotten far enough to see that it is specific to the plugin loading process, and that your image indexes are getting removed after your init.  So we're closing in on what the problem is. 

And I do see the behavior you mention of it working once after a reload - it looks like in this case xretrace.e is getting loaded outside of the plugin loads.  I haven't looked closely as to why this is yet,  but I suspect it's something outside of the plugin system deciding it needs a reload.   Something to look at after the main load problem is fixed.

Found the problem.  I'll put the fix in for the next hotfix.  In the meantime,  you can load the attached copy of cfg.e to get the fix.


[0] Message Index

[#] Next page

[*] Previous page

Go to full version