> Ooops, sorry I was working on it anyway and simply added the necessary > five lines of code (it was *really* easy).
heh, no problem :) I'm intrigued how you managed to replace all the string constants using just five lines of code though Did you create a message dll file (using .mc files) and use FormatMessage to get the text out of the dll or did you do something completely different? What I was doing was to have a directory containing message dlls for each language named something like messages_850_437_.dll messages_615_85_312_.dll where the number is the country locale ( I think these are defined in MSDN if you search for Message Compiler). At load time, the current user's locale is tested to see if an appropriately named DLL is present in the messages folder. If so it is loaded and its handle is used in subsequent calls to FormatMessage. If not, the system's locale is instead tested to try and load a DLL for that (if the system's locale is different from the current user's locale). So for example, if the user's locale is English (UK) (locale number 850) then the messages directory would be searched for, effectively messages*_850_*.dll (the FindFirstFile API makes this a piece of cake) This scheme allows people to effectively create their own localized resource files (in fact they could even simply translate the .mc files and we developers could compile them into resource DLLs... or maybe even just translate a simply text document which we could run through a bit of perl and a custom build script to generate our DLLs for us). The only real alternative scheme as far as I can see would require just one resource dll which is to be replaced with one for the appropriate language. Not so good because it would probably mean having to stop freenet to allow you to remove the existing DLL... and also not at all good on multi-user mutlinationality systems because, if there's only one resource dll, there could only ever be one language for the software or the resource dll would need to be huge and contain ALL language translations ... What do you reckon? > But that does not include the localization of the system tray utility > itself. I am wondering if we should provide localized freenet.exe's, nah ... > a second localized resource.dll nah ... well, maybe. Depends on your answer to above :) > or (my long term favorite) to merge > NodeConfig and Freenet.exe into one application with only one resource > file. What do you think of this? Sounds sensible. Although if we were to do that I might as well do a bit of a rewrite on the freenet.exe thing. If you remember it was only originally rewritten in C just to prove a point (that a freenet control panel didn't need to be written in assembler to be small :-) and as such a lot of the mentality of the coding in the source still adheres to that. Kinda pointless really. If mfc42.dll, msvcrt.dll and (presumably?) msvcp60.dll are needed by the NodeConfig program then freenet.exe could link dynamically against them also - means I wouldn't need to worry about using only kernel32.dll and user32.dll all the time just to save installation hassles, if you're installing them anyway! Also means I can use nice C runtime stuff (e.g. sntprintf, _splitpath, etc) instead of relying on weird stuff (e.g. the Win32 CompareString API, which returns 2 if two strings are the same?!? or writing my own splitpath and GetCommandString-esque functions, which is no fun), and still keep the exe size down (as I would no longer need to link statically to the CRT). David McNab's already suggested the whole proper MFC/MSVC integration of freenet.exe, which I might even consider doing... However, would *not* using MFC cause major problems with integration of the freenet tray utility with NodeConfig? > It would also have the advantage of > being able to simply edit the system tray menu via the MSVC resource > editor. What's your estimation on how sensible/feasible this is? Pretty sensible, and I guess using AFX stuff like message maps and MFC would make implementing changes to the tray menu easier. Everything's feasible. Let's be honest here - freenet.exe still doesn't really do much! So if we get things right /now/ we're more likely to be on the right path in 6 months time. I will be the first to admit that raw Win32 API programming is high-maintenance-high-bugcount stuff and that MFC (despite all its Yiks) would make supporting and enhancing freenet.exe a comparitive cinch. Although raw Win32 API programming is kinda fun in a geeky way. > Sebastian Dave _______________________________________________ Devl mailing list Devl at freenetproject.org http://lists.freenetproject.org/mailman/listinfo/devl
