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

Ideas to make C::B more powerful for refactoring large projects.

<< < (2/2)

rickg22:

--- Quote from: blueshake on November 11, 2009, 06:50:30 am ---The search should highlight the first one match and not destroy the dialogue,so I can continue to press search button to find the word in the line which I am interested in.

--- End quote ---

Wow. Someone who doesn't know the "F3" key. I've been using it since Notepad. Oh, if you press Shift-F3 it goes backwards! :) BTW, thanks for the kudos on Code completion   :mrgreen:


--- Quote from: Zini on November 11, 2009, 10:23:47 am ---
--- Quote ---* Add "Unlist this line" to the context menu.
--- End quote ---
And while you are at it you might want to consider implementing applicable functions from the "Search results (for Find in files):" section in the "Build message" tab, too.

--- End quote ---

Whoa. I just opened Pandora's box. Yelp! :P

Zini:

--- Quote from: rickg22 on November 11, 2009, 01:50:55 pm ---

--- Quote from: Zini on November 11, 2009, 10:23:47 am ---
--- Quote ---* Add "Unlist this line" to the context menu.
--- End quote ---
And while you are at it you might want to consider implementing applicable functions from the "Search results (for Find in files):" section in the "Build message" tab, too.

--- End quote ---

Whoa. I just opened Pandora's box. Yelp! :P

--- End quote ---

Maybe. But when you look at these two tabs (Search results and Build messages) its quite obvious that they are doing the same thing - once the data has been dropped into them. Build messages has the additional feature to display line/file independent summaries (== Build finished: 0 errors, 0 warnings ==), but that is the only difference I can find.

From a software engineering point of view it might make sense to unify the implementation (simply drop the search results implementation and re-use the build message implementation instead? - haven't looked at the code yet).
Possible benefits: It would reduce the total code size and complexity. Both tabs would benefit from additional features like "unlist this line". And it would ensure that both tabs have a consistent style, which is currently not the case (at least on my copy of Code::Blocks the heading uses different fonts/font-effects in the two tabs).

rickg22:
It's not that easy. The two options are handled by loose-coupled code. Search is done in the SDK, while compiling is done by the compiler plugin.

You can't unify code that was designed to be modular.

Zini:
Yeah, had the time to take a look at the code myself. Was quite surprised when a search for the build message tab implementation turned up a plugin source file. Strange! One should think that "source line reference window/tab" makes an ideal candidate for writing a class, that then can be used by what ever part of Code::Block needs it, SDK, Plugin or whatever. Anyway, forget it. I guess it would be more work than it is worth.

Navigation

[0] Message Index

[*] Previous page