Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
Noticed a bug with my TextExporter plugin in 0.3.6: when you export something, it sometimes does not create file at all, although reports that export was successful. More rarely it creates file with zero size. Other times it works correctly. If I repeat the same actions to export, restarting FT between the attempts, the result could be different (no file, correct file, file with zero size).
Previously I used export in 0.3.6 and had no problems, but this was on other computer. I noticed the problem with a multisong NSF, previously I only used export with single song NSFs.
I'm not sure if this is a bug in famitracker. The exporter plugin receives the file name as a string and then it's up to the plugin to handle the actual file operations, I think debugging the plugin is necessary here.
I have no slightest idea what could possibly be wrong in a 200 lines program which is basically
std::ofstream os;
os.open(fileName);
os<< things;
os.close();
and which is actually worked previously without these problems. I also have no idea what to debug there. fileName that received from FT is always correct, that's for sure.
If you think there could not be problems on FT side, OK then.
Actually I'm not sure if the problem is in FT but I assume not since the file is entirely created by the plugin and never touched by FT, especially if you know the file path is correct. I have the source of your plugin here so I'll take a look and see if I find anything.
When I worked on the plugin, using Gradualore's dev builds (he added and removed needed export features in process), I had problems with compatibility - he made changes, I didn't, and program crashed, but in this case it exported at least something, or created empty file if crashed really early.
I assume that in any case, if os.open was executed, an empty file should be created. Nothing happens before os.open, it is the first executed line of code in Export function, so I have no idea how it could work one time and not work other time (under the same circumstances, with exactly the same FTM and action sequence).
Yeah it sounds like a case of using uninitialized memory or something. Not creating a file at all could be the plugin not getting called properly, but that wouldn't explain the empty file.
It works fine here with both single and multisong files. Are you using different OSes on the computer where it worked and where it didn't?
I didn't write the plugin code in FT but I will try and see if I can find anything that might cause problems. Beside that the only thing I can think of is if you have the possibility to run the DLL in a debugger while exporting and see if it gives any clues, I think it's possible to do with visual studio.
Ok I think I found something: the file object is a global object in your plugin, this is usually not recommended in DLLs. Also, the file object is not closed when the function has finished.
It is closed in my WIP version, by some reason it wasn't in public one. Makes no difference for the problem (tested).
I've just made the file object non-global, nothing has changed.
Edit: or maybe changed, after some testing. I haven't seen zero-size file after these changes, and seems it now works more definitely - if I'm trying to save a file into dir with non-latin symbols, it does not work (no file, despite positive report), and if I'm trying to save it into a dir with latin characters only, it worked every time I've tested it now. Non-latin symbols is probably a different problem, related to Windows versions I'm using (maybe localization works differently), although NSF export still works with non-latin paths.
