Building the Right Environment to Support AI, Machine Learning and Deep Learning
Environment: VC6, VC7, Win32
Be Sweet Home page
What's New in Version 0.6
- BeSweet supports now multiple workspaces and Visual Studio instances.
- Initial support for Visual Studio .Net. This is still quite experimental and should be used with caution.
- Completely reworked the Visual Studio Addin. It's now much simpler to get BeSweet running.
- The integration between BeSweet and Visual Studio is now much tighter; in other words, the selected text in the Visual Studio editor will be used as search arguments when clicking on a addin button.
- Improved the Tag-Browsers. The Up/Down arrow key works in the list boxes. If the Matches-List is focused, the typed characters will be used as search arguments (ESC/Delete to clear the filter, Backspace to erase the last typed character).
- Fixed tons of bugs.
If you ever worked with SniFF+, IBM's VisualAge, or its successor Eclipse/JDT, you get used to some features that are hard to miss if you have to change the IDE. VisualAge provides excellent visual class browsers and SniFF+ has the most advanced source code browsers I've seen yet. Although Visual Studio provides a visual class browser, it's absolutely unusable because it's only updated on a compiler run, doesn't show inheritance, and last but not least, shows all classes of the project in a single tree (uuhhm... very funny to search for a class within 300 other classes). Or you know there is class FooManager, or is it named FooMgr, and in which file does it reside? While VisualAge/Eclipse provides a very nice class browser that lets you search a class by its name with simple regular expressions, you are completely left on your memory with VS.
While some of the missing features can be "upgraded" by installing some third-party addins (such as VisualAssist or WorkspaceWhizz), none of them satisfied all my needs. So, after complaining and moaning around for almost a year, I decided to start my own little project, the "Be Sweet" project.
This leaves only one remaining point for the introduction... how come the name?
Well, when I initially started the project, it was named "Eclipse-Style Browsers." While, technically speaking, this would have been the correct name, it's quite long, isn't it? So, then I was thinking about Browser-Suite, which then turned into B-Suite, and that sounds like "Be Sweet" and indeed, it's sweet to have them.
Currently, there are five different kinds of browsers implemented:
- Outline Browser shows the outline of a selected file
- Hierarchy Browser shows the hierarchy of a selected type
- Type Browser enables the search for types by using regular expressions and lets you jump to the declaration
- Method Browser is the same as the type browser but for functions and methods
- Workspace/File Browser is the same as the type browser but for files in the workspace
All browsers have an auto-raise feature. They can be brought to the foreground by hovering the mouse over them (without any mouse click) and when the mouse leaves the dialog, it disappears into the background while Visual Studio is brought to the foreground instead. It takes some time to get used to that feature, but it's very handy once you are used to it. I sometimes catch myself holding the mouse over Microsoft Word, wondering why it doesn't come to the foreground.
It's IMPORTANT to note that you must specify a corner that is used as a measuring point to determine the window currently (partially) covering the browser. By default, this is the top-right corner but can be adjusted in the preferences. Therefore, you should place the browser at the left edge of your screen to make auto-raise work properly.
Oh yeah, all browsers are resizable, of course.
The Outline Browser
This is probably the most-used browser while working; well, at least in my case it is. It displays the content of the active Visual Studio editor. It's updated every time you switch to another file or if save your changes.
The mouse behavior is context sensitive. Clicking onto a class/struct will open an editor containing the declaration of the class (usually this will be a header file) and the declaration line is highlighted. If you left-click on a method or function, the editor containing the definition (implementation) will be opened at the appropriate position and if you right-click on that same method/function, the appropriate declaration will be opened. The middle button will pop up a little menu, allowing you to switch to the header, source, or displaying the hierarchy of the selected class/struct/union.
If the outline browser was brought to the foreground by its auto-raise feature, you can move the mouse back into Visual Studio (the outline browsers will then automatically disappear). The editor will automatically get the focus so you just can start typing without the need to activate/focus any window manually by any mouse click!
The Hierarchy Browser
This view shows the hierarchy of a type. The Type Hierarchy view consists of two panes: the Type Hierarchy tree pane and the Member list pane.
The view can be adjusted to show the type in its full context (in other words, subclasses and superclasses). If the type has multiple superclasses, only the longest "super-path" will be displayed. It can be set to show the super types only (be aware that the the hierarchy tree is displayed upside down) and, last but not least, the view can be restricted to show sub-types only.
The member list pane displays the members of the currently selected type in the type hierarchy tree pane. It can be adjusted to show its "own" members only or to show inherited methods and fields also.
The Tag Browsers
What shall I say about them? Well, they are quite handy if you are looking for something, but can't remember the full name or its location. For example, was that type named TextHandler or TextManager or TextMgr? All tag browsers provide an incremental search and support simple regular expressions (sorry, the "?" doesn't work yet).
The Visual Studio AddIn
The addin is one of the two main parts of the system and implements the role of the BeSweet client. It's registered to several Visual Studio events and triggers the appropriate action on the server; in other words, it loads the workspace if you open a new workspace or triggers a reparse of a source file if that file has been modified.
Selected text in the Visual Studio editor will be validated and used as search arguments when opening a browser via the addin buttons.
For your convenience, hot keys can be bound via Tools->Customize->Keyboard->Add-In. All commands start with "ESB"; for example, ESBShowTypeBrowser would bring the type browser to the foreground.
When I started the project, I had to decide to either fully integrate the browsers inside Visual Studio or to build an external application. After reading a couple of articles about how to integrate custom apps into VS on www.codeguru.com, I decided to build an external client/server application based on the following reasons. First, I wanted to concentrate my effort on the fun part and after reading those articles, integrating an app into VS didn't sound like fun. Second, which is IMO the much more important reason, if the external app crashes, it won't crash VS as well!
As mentioned above, the system is designed with a client/server architecture, where the client is implemented as a Visual Studio addin and interacts with the server via COM. The server's architecture is a very traditional MVC pattern. Not all of the blocks above are currently implemented—there are no QT-Renderers.
Although there isn't/wasn't any need for multi platform support, I tried to avoid too many platform-specific dependencies. STL is used wherever possible, MFC is strictly used in the renderers only, and the COM interface implementation is completely encapsulated in its own module. That said, the effort to port it to another platform shouldn't be too big.
The best way to work with BeSweet is when Visual Studio is NOT in full-screen mode and you place all browsers at the edges of your screen (see also the screen-shot in the source zip).
Installation is very easy. Just follow these steps:
- Unzip the package into a folder of your choice.
- Register/Load the Visual Studio Addin via Tools->Customize->Macros and Add-Ins
- Customize the key binding. I personally use Alt-T to pop up the Type Browser, Alt-O for the Outline Browser, and so forth.
- Start ESBServer.exe.
- Open a workspace in Visual Studio.
It might be neccessary to reboot your computer if you have already installed an older version of BeSweet. If nothing works, do the following:
- Uninstall the addin from Visual Studio.
- Unregister the DLL with regsvr32.
- Reboot your PC.
- Start ESBServer.exe.
- Open Visual Studio and reinstall the addin.
- Press the first addin button and ensure that BeSweet is enabled (only for VC6).
- Open a workspace in Visual Studio.
- Right-click on the BeSweet-SystemTray icon and maximize --> your workspace should be listened here.
How to Build BeSweet
It's not possible to build BeSweet with the default STL shipped with VC++ 6.0. The reason is that the VC STL is based on a pre-existing standard (I think before 1998) and is therefore missing some (important) features. To build the project, any recent STL implementation should work. I personally use STLPort 4.5.3, which is based on the original SGI implementation and can be freely downloaded here.
Credits and Thanks to
- Darren Hiebert for his ctags parser... the enabling part of this project!
- Davide Calabro for his excellent flat-style bitmap button class, CButtonST
- Richard Hazlewood for his formidable multi selection tree control, CMultiTree
- Andy Brown for providing his easy CDynamicDialog class
- Chris Maunder and his CSystemTray class
- Special thanks goes to Ulf Niewoehner, Tsvetan Tsvetanov, and Xiaoming Zhao for their help in testing BeSweet and suggestions for improvements
DownloadsBe Sweet Home page Download binary - 1436 Kb
Download source - 825 Kb