wxIFM, Toolbars & resizing Topic is solved

[eranif]

Hi,

I am porting my application to wx GUI from MFC, and I decided to use wxIFM for the docking system.

I encountered some problems with toolbars & wxIFM and found a workaround suggested by the author of the wxIFM package.

However, I am now facing a new problem:
When using the wxPanel workaround, when I am resizing the main frame, the
docked windows are not adjusting to the new size - so i get 'cut' windows

In my main frame i have the following:

// Add the tool bar
mainSizer->Add(m_standardToolbar, 0, wxEXPAND);
mainSizer->AddSpacer(1);
mainSizer->Add(m_thePanel, 1, wxGROW|wxALIGN_CENTER);
mainSizer->AddSpacer(1);
mainSizer->Add(m_statusBar, 0, wxEXPAND);
SetSizer(mainSizer);
mainSizer->Layout();

Attached you can see the problem, in the picture 1 you can see the editor with the visible windows, and in the second picture - you can see that the not all the windows are visible (even though they are)



Any ideas?

Thx,
Eran

[SnakeChomp]

The probability that this is a wxIFM problem is very low. Can you prove that your sizer is properly resizing your panel? I would do something to check and make sure.

I don't want to tell you how to design your app, but why is "Solution Files" a dockable window? It clearly looks like its the "editor" window, which should simply be a notebook that is set as the content window for wxIFM, one tab per document. wxIFM was not designed to function without a content window, and avoiding one where it is clearly the natural choice is not the right thing to do IMO.

[eranif]

First of all, advises are most welcome. I changed the docking window to be the content window as you suggested:

// Create the book
m_book = new USNotebook(m_thePanel, wxID_ANY, wxDefaultPosition, wxDefaultSize,
wxNB_TOP);

m_ifm->SetContentWindow( m_book );

This does not solved the problem (attached is a screenshot with the content window and the problem still exist )



I am not really sure if the sizer is doing to right job, since I am kinda of newbi to the wx.

In other posts you made here, I saw that you helped a guy to solve a toolbar issue and tested it with the demo source code, Can you please provide the source code for demo that does it correctly? (the main.cpp)

It will be a great help,

Thanks,
Eran

[SnakeChomp]

You do not have the toolbar issue because you are not using wxFrame::CreateToolbar. Using a content window won't fix the problem, as the problem is your sizer, and I don't know whats wrong with it. Maybe if you post more of the code that creates the sizer someone more knowledgable about wxSizers could help you. Be sure to include what object this code is actually in. You call SetSizer but I dont know what object SetSizer is being called on. The wxFrame I assume?

[eranif]

Hi,

First of all thanks for the help, I kinda fixed the problem. It was the function OnSize in the main frame - i forgot to add the line event.Skip() ...

I dont really need OnSize in my main frame - it is a leftover from the wxDockIt - (my first attempt was with wxDockIt, when using it yo must implement the OnSize function, so when I switched over I cleaned the content of that function)

It now works find.

You have any idea of how to reduce the flickering when dragging floating windows?

Thanks again
Eran

[SnakeChomp]

About flickering, I think you should wait until I release 1.0.5 at which point flickering will not be an issue. Many things have been fixed in 1.0.5 but I am waiting to release it pending decisions being made on wxIFM integration into the wxWidgets CVS.

[eranif]

Cant wait to get my hands on it (You can be sure I will test it)

If 1.0.5 is not closed, I would like to suggest something regarding the draging of windows - When you drag the window (I guess it is started when the left mouse is down), I dont think that you should draw the window at the new position until the mouse is released.

This will save painting issues. Other docing packages (such as wxDockIt) does it in a way that once you start dragging a window - a small empty dark frame is drawn until the mouse is released, only then the window is moved/redrawn.

BTW, this only happen when I have an open windows on the background (As you can see in the first picture there is a notebook opened with 6 views opened, all are sxScintilla derived classes)

I am attaching 2 small pictures to clarify what I meant (incase my english is bad)
Bad dragging:


What I think of a good dragging:


What do you think?

Eran

[SnakeChomp]

Microsoft Visual Studio 2005 uses realtime updates when dragging windows, and so does wxIFM. This is how it will stay. I used to use XOR preview rectangles, but was impossible to implement them efficiently and without redraw artifacts. Other docking packages do not use "dock buttons" as I do and do not have to contend with them moving around causing display artifacts. Those docking packages which use XOR previews suffer from not having the "dock buttons" and force the user to "guess" where they need to put that XOR rectangle for something useful to happen. Making the user guess how to do stuff in the application is bad, which is why wxIFM (and Visual Studio 2005) use dock buttons and realtime drag updates.

You are seeing the artifacts when dragging over your editor windows because you are most likely in debug mode, and wxScintilla is drawing very slowly. It is not my fault that wxSTC is slow, and there really isn't any advice I can give you there other than trying a release build.

[eranif]

Ok, understood.

FYI: What I finally did is i rebuilt the library with the define IFM_CANFLOAT set to 0 to disable the floating capability (the drawing issues i get when moving a floated document over scintilla is terrible, and I cant abandon scintilla so i had to compremise here...)

What I will do next is to change the icon when user tries to move a window to something more nice then the 'forbidden' icon.

PS: I have another question regarding wxIFM - but I will open new thread since I way off topic here already

Thanks for the help,
Eran