MacOSLib annoyingly writes to Resources Folder in Win32 Build

Hi. I’m working on the Win side of my app at the moment but will eventually make it cross-platform so have included the MacOSLib in my project so I can refer to both target codes as required but for some reason the Win build still writes some files to the Resources folder.

They are something to do with the NSSearchField class since they create a handful of en.mo, bn.mo etc files. Inside these files they have “NSSearchField.ClearSearchesLocalizedText” among other NSSearchField constants.

I’ve hunted through the code but can’t seem to find where it is executing the file writing since most of the code is in Cocoa pragmas.

Does anybody know how to stop this?

Can’t you simply delete the files with a build script?

[quote=132342:@Denise Adams]Hi. I’m working on the Win side of my app at the moment but will eventually make it cross-platform so have included the MacOSLib in my project so I can refer to both target codes as required but for some reason the Win build still writes some files to the Resources folder.

They are something to do with the NSSearchField class since they create a handful of en.mo, bn.mo etc files. Inside these files they have “NSSearchField.ClearSearchesLocalizedText” among other NSSearchField constants.

I’ve hunted through the code but can’t seem to find where it is executing the file writing since most of the code is in Cocoa pragmas.

Does anybody know how to stop this?[/quote]

Seems strange that MacOSLib would create files on a Windows system. Are you sure you don’t have some methods without a pragma that can create these files ?

But everything is possible. One way of verifying that it is indeed a problem with it would be to remove it and attempt a build. I gather all your mac code is using conditional compilation. If MacOSLib is the origin of the files, the should not show. But that may not be possible.

I tried to a search on the MacOSLib master project to look for the file names you mentioned, or for the string “NSSearchField.ClearSearchesLocalizedText” and it is not present in there. Then I looked for “textoutpustream” and none of the three methods that use that seems called. But you may place a return at the beginning of WriteToFile() and MakeTempFile so they no longer be able to create any file.
You can do the same for the number of methods that use binarystream as well.

Just thinking : would you have other third party classes besides MacOSLib that could generate these files ? The searches I mentioned should spot them anyway.

MacOSLib is itself localized so when you compile the IDE actually generates an MO file for each localization.
Basically to get rid of those files you have to go through & strip out all the localizations in MacOSLib OR post process your built app to just delete them.

I’ve mentioned this to the maintainers of MacOSLib.
See https://forum.xojo.com/2404-macoslib-advice/0#p16945
https://forum.xojo.com/8624-app-languages-in-mac-app-store

Hi. Thanks for all the suggestions. I checked for WriteToFile() and MakeTempFile and couldn’t find anything that would be causing the problem. I have never used Build Automation before so don’t know how to write a post-build script for Win32 to delete these resource folder files. If anyone has a script example (the links provided seems to be MacOS script code I think) then please post otherwise I think I’ll just have to remember to delete these files manually before distribution.

Its not MacOSLib writing files

The compiler creates these based on the data IN macOSLIb - specifically various localized strings.

Go Insert/Build Step/Script, and drag the script after the gear in the Windows build settings.

IDE scripting is described in UserGuide- Frameword.pdf, page 203 onward. The variable CurrentBuildLocation gives you the path to the folder containing the built app, so you should be able to do something like this to remove all the .mo files in the Windows Resources folder.

dim result as string result = DoShellCommand("rm "+CurrentBuildLocation+"/Resources/*.mo"))

This works on a Mac. On Windows,

 result = DoShellCommand("del "+CurrentBuildLocation+"\\Resources\\*.mo"))

That works great. Thank you!