wxFileName::AssignCwd() and wxFileName::SetFullName() problems

[Volker Bartheld]

Hi Vadim!

>VB> >VB> I'm aware of wxStandardPaths. Actually I would need a portable
>VB> >VB> equivalent of Win32's ::GetModuleFileName(NULL, ...)
>VB> > Well, this is what wxStandardPaths is (and more).
>VB> ... in 2.8.0, such as wxStandardPaths::GetExecutablePath(). ;-)

> You should _not_ use GetExecutablePath() for finding your data files. The
>fact that you think that you need to use is the primary reason why I was so
>much against adding this function in the first place.

Actually, it's not _me_ who opted for this. And, yes, we have different
implementations for GetDataFolderOfApplication() and the Win32
implementation uses ::GetModuleFileName() (for historic reasons).

It's the same old thing with writing configuration data. First, there
was the .ini file in %WINDIR%. Then, everybody should use HKLM/Software
in the registry. Later, HKCU/Software was the way to go. Meanwhile,
there are tendencies towards having apps to write .ini (or .xml) files
again, but this time into %APPDATA% or %ALLUSERSPROFILE% (wherever this
is available).

Since our app deposits it's default data templates in a subdirectory of
the main binary for Win32, it was decided to use & tweak
::GetModuleFileName(). For Linux, I don't even know how this was done (I
have to ask the distribution guys).

>Please do read
>wxStandardPaths documentation and choose one of the functions which returns
>path to data/config files

Sure this would be the correct way. Let's hope this is also maintained
by every installer we use.


Thanks for pointing this issue out. We're totally d'accord when it comes
to not breaking an OS' native behaviour. This is why we use wxWidgets.

Cheers,
Volker
__
Mail replies to/an V B A R T H E L D at G M X dot D E