Re: [lmi] wxmsw-2.9.0 (svn trunk) anomaly

[Greg Chicares]

On 2009-02-26 00:37Z, Vaclav Slavik wrote:
> 
> On Mon, 2009-02-23 at 19:32 +0000, Greg Chicares wrote:
>>  - thus: './lmi_wx_shared --figure_it_out --data_path=/opt/lmi/data'
>> I get:
>> 
>> 18:34:25 PM: Can not enumerate files 'opt\lmi\data\skin.xrc' \
>> (error 3: the system cannot find the path specified.)
>> 18:34:25 PM: Cannot load resources from '/opt/lmi/data/skin.xrc'.
> 
> Note that because LMI is built as native MSW app, "truly" absolute path
> to --data_path would be c:/opt/lmi/data or, better yet, c:\opt\lmi\data
> (although /opt/lmi/data = \opt\lmi\data is a valid MSW path, absolute on
> the current disk).

That's the reason why I considered it imperative to fix lmi on
20090329T0236Z as in (3) below. Cf. this question:
  "Why are fully specified paths called complete rather than absolute?"
in the boost filesystem FAQ. What boost calls a "complete" path is just
"absolute on the current disk" for msw--absolute only in a relative way;
system_complete() is the closest we can come to absolute in an invariant
sense, AFAICT.

> (2) I also added wxXmlResource::LoadFile(wxFileName) that doesn't suffer
> from this ambiguity in r59150
> (http://svn.wxwidgets.org/viewvc/wx?view=rev&revision=59150). In LMI
> code, calls to xml_resources.Load() could -- and in my opinion should --
> be replaced with xml_resources.LoadFile() to avoid the ambiguity.

Given that I've done (3), is it still your opinion that lmi should
use LoadFile() instead of Load()?

> (3) Finally, the bug wouldn't manifest itself if
> global_settings::data_directory() returned absolute path. This is only a
> workaround that hides the real wx defect, of course. However, I think it
> still makes sense to do it, because it makes data_directory() resistant
> to CWD changes and that is IMHO a good thing (even though LMI currently
> doesn't change CWD as far as I can tell). A patch for this is below [*].

I have a suspicion that most apps built for msw may change CWD via (e.g.)
the builtin msw file-open and file-save dialogs--at least for some msw
variants. I haven't observed that myself, but our most knowledgeable end
user (who's the only one with programming experience) insists that she
observes this--specifically, that a file created by lmi thus:
  std::ofstream os("filename_with_no_path");
is written to an indeterminate directory.

With the following experimental msw-specific patch, I can see CWD change
on the statusbar while a file-open dialog is displayed. I see it revert
to its former value when that dialog is closed, but perhaps other msw
variants behave differently.

Index: main_wx.cpp
===================================================================
RCS file: /sources/lmi/lmi/main_wx.cpp,v
retrieving revision 1.132
diff -U 3 -r1.132 main_wx.cpp
--- main_wx.cpp 26 Mar 2009 16:47:29 -0000      1.132
+++ main_wx.cpp 29 Mar 2009 11:36:02 -0000
@@ -1060,6 +1060,8 @@

 void Skeleton::UponTimer(wxTimerEvent&)
 {
+char buf[MAX_PATH];
+status() << getcwd(buf, MAX_PATH) << std::flush;
     if(0 == fenv_guard::instance_count())
         {
         if(!fenv_is_valid())