StyledEdit "Save As..." window does not open under certain circustances.

[bga]

I guess I saw it happen in more than 0ne case, but this is one way i can reproduce it 100% of the time.

1 - Open StyledEdit. 2 - Write something. 3 - Mount any partition other than the boot one (does not even need to be a writtable one). 4 - Select "Save As..." and try to save to any path inside this newly mounted partition. 5 - Now unmount the partition. 6 - Try to "Save As..." again.

Expected behavior:

"Save As..." window opens.

Observed behavior:

"Save As..." window did not open.

[siarzhuk]

Published as GCI 2013 task.

[anevilyak]

From a quick look at this ticket, this may not be the wisest thing to issue a GCI task for.

The actual problem lies down in BFilePanel itself, at least with the above steps to reproduce: A normal Tracker window will close itself when the folder it's displaying goes away. Meanwhile, StyledEdit keeps its file panel around and reuses it in order to remember the last location the user browsed to.

In the above instance, upon volume unmount, the hidden window notices that via node monitor, and dutifully quits itself, so when StyledEdit asks the panel to re-show itself again in response to Save As, it silently fails due to failing to lock its (no longer valid) child window.

Fixing this will possibly mean some Tracker refactoring, as I'm not sure if the appropriate hooks are present for the aforementioned behavior to be overridden by a BPoseVIew/ContainerWindow child class.

[siarzhuk]

Replying to anevilyak:

The actual problem lies down in BFilePanel itself, at least with the above steps to reproduce: A normal Tracker window will close itself when the folder it's displaying goes away. Meanwhile, StyledEdit keeps its file panel around and reuses it in order to remember the last location the user browsed to.

IMO it is not the problem of API if some credulous program uses imprudently some _pointed_ resource that it not owns completely. Even if this API was designed untidy. ;-)

In other words I see here just issue of using this object in some unusual way - so some additional awareness should be introduced in SE.

In the above instance, upon volume unmount, the hidden window notices that via node monitor, and dutifully quits itself, so when StyledEdit asks the panel to re-show itself again in response to Save As, it silently fails due to failing to lock its (no longer valid) child window.

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

[anevilyak]

Replying to siarzhuk:

IMO it is not the problem of API if some credulous program uses imprudently some _pointed_ resource that it not owns completely. Even if this API was designed untidy. ;-)

In other words I see here just issue of using this object in some unusual way - so some additional awareness should be introduced in SE.

Be themselves recommended using file panels in precisely this way back on the BeCodeTalk mailing list when people asked about having panels remember their last location, so this wasn't exactly something undocumented. Furthermore, the docs specifically indicate that the panel is only supposed to hide itself after the user is done browsing, not destroy entirely, so no, this isn't any unusual use based on the class specs.

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

The only reason I did so was because the student asked for some help, as his attempts to debug the issue were resulting in a double fault panic in virtualbox every time, the cause of which currently isn't known. In any case, fixing the underlying libtracker issue isn't what I'd call low hanging fruit without some knowledge of Tracker internals, which I doubt the GCI students have.

[siarzhuk]

Replying to anevilyak:

Replying to siarzhuk:

Thanks for investigations. There are something to say about - but I have to keep silence until the end of GCI. This "fruit" is hanging too close after your have explained the source of problem. ;-)

The only reason I did so was because the student asked for some help, as his attempts to debug the issue were resulting in a double fault panic in virtualbox every time,

the cause of which currently isn't known. In any case, fixing the underlying libtracker issue isn't what I'd call low hanging fruit without some knowledge of Tracker internals, which I doubt the GCI students have.

I tend to not underestimating them. Beginners usually have no "blinders" on theirs eyes. I suspect, I'm not the only person that asking "Why the routine that [can] fails do not return any [un]success code?" ;-)

[anevilyak]

Replying to siarzhuk:

I tend to not underestimating them. Beginners usually have no "blinders" on theirs eyes. I suspect, I'm not the only person that asking "Why the routine that [can] fails do not return any [un]success code?" ;-)

You won't find me disagreeing there :-) Unfortunately changing that particular case would result in ABI compatibility breakage, as BFilePanel::Show() is public.

[scottmc]

Can someone check over this patch and either apply or it reply here with more info?

[pulkomandy]

It only works around the problem explained above. We should instead fix BFilePanel so it doesn't delete itself as mentionned in the ticket.

[siarzhuk]

Those were taken some years ago as potential GCI tasks. Unfortunately no place is available for them in my schedule at this days.

[KapiX]

Fixed. (Probably by hrev51502.)