Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

New log manager since rev. 4606

<< < (6/9) > >>

thomas:
If you want a function to hide a log tab, then this could be implemented in InfoPane, if you can give a good reason.
InfoPane does have a Show() member already to allow you to bring a tab into the foreground, if something crucial really has to be shown and put in the foreground (for example a critical error, or search results after a lengthy search). A Hide() member was deliberately omitted because it is generally not your decision what logs are shown, but the user's (selectable from the popup menu).

If you want to do word by word what you said ("my log window to be removed from the logger") then it gets complicated.
LogManager takes Loggers (with GUI or without), and owns them.
InfoPane asks (on behalf of LogManager) all Loggers to provide a GUI control (which they can do, or not). If a Logger does provide a control, InfoPane takes ownership and adds it to the notebook.
Giving up ownership on either of the two may be problematic, and I don't see a real urgent need for it.

You probably want this functionality for the ThreadSearch plugin, right? If so, then using a Logger is not the best solution anyway. You are not logging anything, so you shouldn't be using a Logger.

InfoPane has a function to add non-loggers to its tab list, too. This function takes anything derived from wxWindow, it does not require a Logger, nor does it own a Logger or install one into LogManager, nor does it delete one. That function was added to give the possibility to add something into the log area which actually does not belong there (as it is no log), but still belongs there somehow (as people are used to find it there).

dje:

--- Quote ---if you can give a good reason
--- End quote ---
Well, we'll have to discuss what makes a reason to be good  :D but:
Previous MessageManager worked like that.
No access to InfoPane is provided (and I think it's a better design choice).
I'd like to transfer ownership of my control from Messages notebook to the Layout on the fly. From a user point of view, I find very BORING the "Change will take place at next application start". And I find more pleasant being able to use Messages notebook or Layout management for the plugin without restarting the application.

That is why I need a removal without deletion.


--- Quote ---You probably want this functionality for the ThreadSearch plugin, right? If so, then using a Logger is not the best solution anyway. You are not logging anything, so you shouldn't be using a Logger.
--- End quote ---
Yes, I need it for this plugin to keep the same behaviour. If it is not the right place for it, is it the place for the "Search results" tab ?
That's the same feature except there is a preview window and a non blocking search.


--- Quote ---InfoPane has a function to add non-loggers to its tab list, too. This function takes anything derived from wxWindow, it does not require a Logger, nor does it own a Logger or install one into LogManager, nor does it delete one. That function was added to give the possibility to add something into the log area which actually does not belong there (as it is no log), but still belongs there somehow (as people are useNonLogger,d to find it there).
--- End quote ---
I saw it and I agree but no events exist to access it. And I would need a RemoveNonLogger, not a DeleteNonLogger call.
I tried to reparent my ThreadSearchView to avoid the parent window to destroy my wxWindow but as the wxWindow is referenced in a structure and an explicit Destroy is called, there is no workaround.

Nevertheless, I find that, in the present implementation, EVT_REMOVE_LOG_WINDOW is confusing.
That is reenforced by InfoPane implementation with its Remove and Delete methods.

Dje

thomas:

--- Quote ---No access to InfoPane is provided (and I think it's a better design choice).
--- End quote ---
There is no real access to InfoPane, at least not one that is to be used without good reason. The idea behind the new LogManager and the InfoPane is that LogManager runs regardless of any GUI capabilities (in fact, without any capabilitites at all, not even console I/O or file access). InfoPane is a GUI class that builds a bridge to a GUI, in this case the notebook window that we see on the bottom. If InfoPane isn't there, LogManager still works the same (as for example when doing a batch build). Thus, no special branches are needed for this, everything works the same.
I think this is a better design, but surely opinions can differ on that.

For you, LogManager, Logger, and anything related to them actually does not matter. You don't really log anything. Thus, whatever happens with Loggers really isn't so important, since you would really want to add a non-Logger.


--- Quote ---And I find more pleasant being able to use Messages notebook or Layout management for the plugin without restarting the application.  That is why I need a removal without deletion.
--- End quote ---
That is no good reason. You should be using a non-Logger (even if you derive your panel from a Logger-subclass, you can still add it as non-Logger).


--- Quote ---I saw it and I agree but no events exist to access it.
--- End quote ---
Yiannis probably just forgot to add those, since there are very few valid uses for them anyway. But... it's not like it isn't supported :)


--- Quote ---And I would need a RemoveNonLogger, not a DeleteNonLogger call.
--- End quote ---
This exists.

dje:
I totally agree on the fact I should use a non-logger but it is impossible for now as there no access  to the infopane (direct or events).
That's why I chose the logger way that makes me add useless code to comply with available interfaces.
Whatever (non)logger it is, it is systematically destroyed and that is my real problem.

I totally agree this evolution makes software design cleaner but something is broken or missing because i can not do any more what was possible.

Before, there was a mix between LogManager and MessagesManager.
First step is reached, the log part is OK.
Second step is partially reached because developer looses a lot of possibilities.

As there is a wxWindow* Logger::CreateControl method which is triggered for window creation, it could be nice to have a OnRemoveControl which could veto or tell if wxWindow must be removed or destroyed. It could be an alternative solution to a new event type.

As you wrote, lots of what I need is available but some bridges are missing to link them.
So, what, who, when ?

Dje

dje:
Hi all !

In sdk_events.cpp

--- Code: ---CodeBlocksLogEvent::CodeBlocksLogEvent(wxEventType commandType, wxWindow* window, const wxString& title, wxBitmap *icon)
: wxEvent(wxID_ANY, commandType),
logger(0), logIndex(logIndex), icon(icon), title(title), window(window)
{
logger = Manager::Get()->GetLogManager()->Slot(logIndex).GetLogger();
}

--- End code ---
logIndex auto affectation gives out of range value (98443884 according to GDB).

my code:

--- Code: ---CodeBlocksLogEvent evt(cbEVT_REMOVE_LOG_WINDOW, m_pThreadSearchView);
Manager::Get()->ProcessEvent(evt);

--- End code ---

Crash

BerliOS bug : 12700

Thanks for non deletion of non logger window in cbEVT_REMOVE_LOG_WINDOW event management in 2nd December build !

Dje

Navigation

[0] Message Index

[#] Next page

[*] Previous page