A new sample has recently been added to , called Journal.urd. While Ultra Recall can do much more than just managing a journal, it is very good at the task, which this sample highlights. The sample demonstrates using templates and other Ultra Recall features, and contains a pre-configured journal hierarchy. A flash tutorial about managing a journal in Ultra Recall is also available .
The Journal.urd sample shows one method of creating a journal hierarchy in Ultra Recall, but you are certainly not constrained to this design, the flexibility of Ultra Recall allows limitless configurations. The sample uses three custom templates (Year, Month, and Journal Entry), which makes it very simple to add Journal Entries which are organized by Year and Month, yet be fully searchable. Custom icons were assigned to the different templates which further highlights the different parts of the journal.
There are many reasons why Ultra Recall is a great application for a journal:
All data is stored in a single file: this makes it very easy to backup, or transport your journal
Strong password encryption: a single password will ensure your journal is secure, even if it is located on a USB drive or other transportable media
Powerful and flexible search capabilities: as your journal grows, you will have the confidence that you can find the information if you need to
Automatic spell-checking: similar to the spell-checking available in Microsoft Office, this feature helps you avoid typos
Custom templates: this feature is demonstrated in the sample, and is used to add structure and convenience to your journal experience
Ability to add supporting information (documents, emails, web pages, etc): this is the real beauty of Ultra Recall, it can function as a regular outlining application, but also has the flexibility to do much more, by storing essentially anything!
Logical Linking: if you can’t decide what a topic is relatd to, this technology will let you link it to them all! Very handy in a topical hierarchy like a journal
No limits on journal size: since Ultra Recall uses the SQLite embedded database engine, it provides high performance with consistent performance regardless of file size. You won’t be constrained to any artificial organization limitations with Ultra Recall!
Other applications can be used to manage a journal, but Ultra Recall excels at the task, while offering many additional capabilities. Ultra Recall quickly becomes indispensable, by managing your scheduled tasks; archiving your emails, documents, web pages and text together, organized topically, chronologically, etc; then facilitating the recall of everything added with powerful search capabilities.
Our are written primarily in . We started with Visual C++ 6.0 back in 1998 and used it successfully for many years.
VC7
There was quite a bit of disappointment among C++ developers with the release of Visual Studio .NET (VC7) in 2002 and VS .NET 2003 (VC7.1) the following year because of so much emphasis placed on the new and VB.NET and C# languages. But with some trepidation and a moderate amount of pain, we finally migrated to VC7.1 in mid-2005. Other than some quirks in the resource editor that we managed to work around, that version worked well for us (with the requisite additions of and add-ins). It brought much-needed improvements to standards compliance, some library improvements, and was fairly stable, although compilation was a little slower and the executables slightly larger than VC6.
VC8
In early 2007, we experimented with upgrading to (VC8) but ran into a lot of problems attempting to get everything to compile and link properly. Microsoft also made some changes to how LIB files are handled, and one third-party library we use did not offer a VC8-compatible library at the time, so we shelved the conversion.
With Microsoft readying the release of (VC9) and the availability of VC8-compatible third-party libraries, we decided it was time to attempt migrating one more time. We thought it would be easier to convert to VC8 first and then try VC9 after that, but boy did that turn out to be a poor assumption.
VC8 didn’t do a great job of converting our project and solution files, requiring manual correction (Build checkboxes in the Configuration Manager and dependencies getting dropped). We also ran into several compilation and linker issues to work through, including:
Several code changes were required to eliminate warning messages related to using the new safe CRT functions calls, etc.
Had to increase the compiler limits (/Zm) on some projects
Warning for non-standard extension used in qualified name for enums
Disabled manifest generation and embedding (since our executables already include a manifest)
Thanks to ’s built-in support for all Visual Studio releases, updating our builds was painless (only needing to append ‘|Win32′ to the solution configuration names).
Once we finally got everything to compile and link, we ran into several runtime problems and had to make some more changes, primarily:
Avoid referencing &elem[0] of empty vectors (it’s safe to pass that to memcpy with a length of 0, for instance, but VC8 aborts the program just by referencing the element)
Make changes to bring STL iterator code (which assumes they are pointers) into compliance
Most problems were identified quickly and corrected in the debug build, but even with these changes, we ran into two show-stoppers:
Choosing one feature in one of our applications resulted in the app just disappearing, and this only occurred in the release build on a Windows 2000 box.
Command-line builds worked fine, but compiling almost any file in any project within the Visual Studio IDE resulted in the dreaded (ICE), which made development and debugging unbearable.
VC9
We were about to give up and stick with VC7.1, but as a last-ditch effort, we decided to try migrating everything to VC9. We encountered a few more compilation issues:
Some of our projects defined a minimum Windows version of NT 4 (_WIN32_WINNT 0×0400), which now resulted in compile errors, but changing this to Windows 2000 (0×0500) fixed that and is safe since our applications require Windows 2000 anyway
The 64-bit portability check compiler flag is deprecated so we removed that directive from the project files
MFC no longer handles including of afximpl.h very nicely, so we just copied the few lines of code we used from that file into our own sources and removed the include
After these changes, low and behold, we found that everything worked just great! No more crashing of the compiler when building in the IDE, and no more problems running our application on Windows 2000. Our executables are larger still (about 10%), which is acceptable considering all the improvements that have been added to make the code more secure in our connected world.
It’s apparent that Microsoft has really put significant effort into improving their C++ tool chain with this release of Visual Studio, and there are many great IDE improvements as well:
The debugger, especially peering into STL containers, has improved tremendously
The resource editor is improved and now handles high color bitmaps
VS/MSBuild now supports parallel builds on multi-core and multi-CPU systems (and builds do appear to be noticeably faster on such systems)
New features like testing, optimization, code snippets, and property manager capabilities
Easy backup, restore, and sharing of IDE settings
One caveat that bit us: Visual Studio 2008 requires Windows XP or later, and our build boxes were all Windows 2000, so we had to reconstruct the build machines. There is also a quirk with the Visual Studio 2008 — it doesn’t install cl.exe and some ancillary files unless you perform a full installation.
Overall, it took longer than expected to complete the migration, but fortunately it turned out to be worthwhile in the end.
