RoboCache for Windows offline files cache management

I’ve written before about RoboCache, a command line utility I wrote for managing the offline files cache in Windows Vista, Windows 7, and now Windows 8. After using the utility internally for a few years, I decided that I might as well clean it up and make it available to the rest of you. RoboCache is now available at the ManuSoft web site. There is a shareware version available, and you can purchase the registered version at the ManuSoft store (cost is 25 USD for a single user license).

It’s nothing fancy, but it works great for my needs. The command syntax is modeled after the ROBOCOPY command, and is designed for handling an entire directory tree recursively, filtering files and folders by wildcard. My typical use case is running it from a batch file to pin remote Visual Studio project files on my laptop before travelling. Visual Studio project folders contain a lot of temporary build files and output files that don’t need to be (and therefore shouldn’t be) included in the cache. The goal is to pin only the necessary files, ignoring the ones that are not needed or will be recreated when the project is built. Here’s a sample call to recursively pin all files in the ‘Build’ folder (this is all one line in a batch file executed from the laptop):

ROBOCACHE Build /op:pin /s /xd debug* release* x64 Win32 .svn _* obj bin ipch /xf *.log *.tlog *._ls *.ncb *.user *.suo *.aps *.ilk *.pch BuildLog.htm *.err *.dmp *.pdb !*.bat #*.bat *.chm *.dia *.aps *.lnk *.Res.dll *.zip *log.txt *report.txt *.winmerge *.sdf *.opensdf

Programmers might notice that the /xd (ignore directories) and /xf (ignore files) wildcard lists look very similar to what one might encounter in a Subversion commit script. In fact, when I created the batch file I just copied and pasted from my SVN ignore lists. For me, the benefit of using RoboCache in this way is that only the minimum needed files are cached. After working on the cached files while I’m out of the office, my changes automatically sync to the folders on my desktop when I return to the office. I do use Subversion repositories for all my projects, and could just as well commit my remote changes to the repository, then update my desktop from the repository; however by using the offline files cache, the syncing all happens automatically and I never have to think about it.

RoboCache can do more than just pin and unpin files. It can perform any of ten operations on the target files (or any of four administrative functions on the files cache itself), including some operations that are not exposed through the Windows user interface. Below is a list of all currently supported operations (captured from the help screen, and not showing the available command line options for each operation).

/OP:cmd :: OPeration to perform (default is /OP:info).
:: info : display status info about the target(s)
:: pin : assure offline availability
:: unpin : unpin the target(s)
:: sync : synchronize cached files with remote files
:: rename : rename cached item (requires reboot)
:: delete : delete cached item
:: suspend : suspend the target folders (ignores files)
:: unsuspend : unsuspend the target folders (ignores files)
:: online : transition to online state
:: offline : transition to offline state
:: enable : enable offline files cache (ignores target)
:: disable : disable offline files cache (ignores target)
:: encrypt : encrypts offline files cache (ignores target)
:: decrypt : decrypts offline files cache (ignores target)

The installer simply adds RoboCache.exe to your system folder; no folders are created and no other changes are made. The shareware version of RoboCache displays a nag notification balloon in the system tray, but is otherwise completely functional. There is no separate documentation, however ROBOCACHE /? displays syntax and command options.

Polymorphic bit flags in C++

I often encounter cases in ObjectARX programming where numerous boolean flags need to be persisted as part of an AutoCAD database object. For filing and for passing around to other functions, it’s most efficient to package those bit flags into a single unsigned integer. Below is an example that demonstrates how to use a union inside a containing class that can be simultaneously used as either a single unsigned integer or as individual booleans.


// first declare a compact bitflag structure as bool values
struct FlagsAsBools
{
bool flag1 : 1;
bool flag2 : 1;
bool flag3 : 1;
bool flag4 : 1;
bool flag5 : 1;
bool flag6 : 1;
bool flag7 : 1;
bool flag8 : 1;
bool flag9 : 1;
bool flag10 : 1;
bool flag11 : 1;
bool flag12 : 1;
};

// now the containing class with useful constructors and operators
class Flags
{
protected:
// and the hidden union that actually contains the flags
union _Flags
{
FlagsAsBools asBools;
Adesk::UInt32 asUInt; //space for up to 32 flags
} mFlags;
public:
Flags()
{
mFlags.asUInt = 0;
}
Flags(Adesk::UInt32 flags)
{
mFlags.asUInt = flags;
}
Flags(const FlagsAsBools& flags)
{
mFlags.asBools = flags;
}
operator Adesk::UInt32 () const { return mFlags.asUInt; }
const FlagsAsBools& asBools() const { return mFlags.asBools; }
FlagsAsBools& asBools() { return mFlags.asBools; }
};

// now a class that contains the flags
class Settings
{
AcString msSomeStringSetting;
bool mbSomeBoolSetting;
Flags mFlags;
public:
Settings () : mbSomeBoolSetting(false) {}

LPCTSTR someStringSetting() const { return msSomeStringSetting; }
void setSomeStringSetting(LPCTSTR someStringSetting) { msSomeStringSetting = someStringSetting; }
bool someBoolSetting() const { return mbSomeBoolSetting; }
void setSomeBoolSetting(bool someBoolSetting) { mbSomeBoolSetting = someBoolSetting; }
Flags flags() const { return mFlags; }
void setFlags(Flags flags) { mFlags = flags; }
};

// now use the flags as an argument to a function in different forms
void DoStuffBasedOnFlags( Adesk::UInt32 flags )
{
if( Flags(flags).asBools().flag7 )
{// do something when flag7 is set
}
}

void DoOtherStuffBasedOnFlags( const Flags& flags )
{
if( flags.asBools().flag1 )
{// do something when flag1 is set
}
}

void TestIt()
{
Settings& MySettings = GetSettings();
Flags flags = MySettings.flags();
if( flags.asBools().flag4 )
{// do something when flag4 is set
}
DoStuffBasedOnFlags( flags );
DoOtherStuffBasedOnFlags( flags );
flags.asBools().flag2 = true;
MySettings.setFlags( flags ); //save the new settings
}

Checking function return values

A lot of you are guilty of not checking return values from API function calls. I’ll bet you have a good excuse, like “it’s a lot of extra typing for no reason”, or “that function should never return an error code”.

I check return values religiously, use asserts liberally, and never assume that the implementation details of a function won’t change in the future. I think you should do the same.

In all my years of programming, I’ve never heard someone complain that their project failed because they spent too much extra time typing code to verify return values – but I have heard of projects failing because sloppy code made it almost impossible to diagnose and fix problems.

I see a lot of “sample code” posted on the internet in forums and blogs that omit error checking for brevity or to make the code clearer to read. That’s a bad idea, in my opinion. Sample code should be good code, not just clean code.

I will grant you that there are cases where error checking is not needed. For example, in the following code there is no need to verify the result of the call to acdbGetObjectId() because failure will be immediately evident in the call to acdbOpenObject() when idSelected is still null:

Acad::ErrorStatus MyFunction()
{
ads_name anameSelected;
ads_point apointSelected;
int nResult = acedEntSel( ACRX_T(“\nSelect an object: “), anameSelected, apointSelected );
if( nResult != RTNORM ) return eNotAnEntity; //or whatever
AcDbObjectId idSelected;
acdbGetObjectId( idSelected, anameSelected ); //ignoring return value!
assert( !idSelected.isNull() ); //check it nevertheless in the debug build
AcDbEntity* pEnt = NULL;
Acad::ErrorStatus es = acdbOpenObject( pEnt, idSelected, AcDb::kForRead );
if( es != Acad::eOk ) return es;
// do something with pEnt
pEnt->close();
//I confess that I don’t bother checking the
//result of AcDbObject::close() unless it matters
return Acad::eOk;
}

There are legitimate cases where error checking is not needed, but I think especially sample code posted on the internet should encourage good programming habits by checking the result of every function that returns one.

Registering an ARX/BRX module as a COM server

If you’re developing ARX modules that need to be registered as a COM server, you’re faced with some decisions about how to register them. In the old days before anyone cared about user permissions, registration could be safely accomplished at runtime, even via AutoLISP. Unfortunately runtime COM server registration just doesn’t work reliably any more under limited user accounts, not to mention registry redirection on 64-bit platforms. There is only one reliable way to register COM servers, and that’s doing it at install time under elevated privileges.

A normal Windows application might accomplish install-time registration by calling RegSvr32 after the files are copied to the destination folder, but this doesn’t work with ObjectARX or BRX modules. The reason it doesn’t work is because ARX modules cannot be loaded outside the AutoCAD or Bricscad process. RegSvr32 will fail with errors like “The module <filename> failed to load” or the even less helpful “The specified module could not be found.” There are some kludgy ways to get RegSvr32 to work anyway, but the simplest and most reliable way to solve this problem is to forget RegSvr32 and just add the needed registry values manually into your installer script. It’s not difficult, though it might be time consuming initially if your server implements a lot of COM objects.

At a minimum, a COM server must register at least one COM class under HKCR\CLSID. If the COM server needs to support OLE Automation (e.g. VBA, AutoLISP) it must register a type library in HKCR\TypeLib. In most cases, this is all that is needed, however you may also need to register a “ProgID” in HKCR if a script or in-process module needs to be able to connect to the server via human-readable ProgID.

Most installation script software can import Windows registry script (.reg) files, so it’s often helpful (and more maintainable) to create a registry script file manually, then simply import the .reg file into the installation script. If you use Visual Studio deployment projects, this is the only way to batch import registry values into the installation script. I’ve provided a minimal template for a registry script that registers a single COM object and ProgID. The template uses special characters as placeholders for the actual values: $$ is the human readable ProgID name, ## is the COM object’s CLSID, ** is the filename of your ARX module, and %% is the type library GUID. The type library and object class version numbers should match your actual version numbers as well, and of course [TARGETDIR] is the installation target directory that will be resolved at install time.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\$$.1]
@=”$$ Class”

[HKEY_CLASSES_ROOT\$$.1\CLSID]
@=”{##}”

[HKEY_CLASSES_ROOT\CLSID\{##}]
@=”$$ Class”

[HKEY_CLASSES_ROOT\CLSID\{##}\InprocServer32]
@=”[TARGETDIR]**.arx”
“ThreadingModel”=”Apartment”

[HKEY_CLASSES_ROOT\CLSID\{##}\ProgID]
@=”$$.1″

[HKEY_CLASSES_ROOT\CLSID\{##}\Programmable]

[HKEY_CLASSES_ROOT\CLSID\{##}\TypeLib]
@=”{%%}”

[HKEY_CLASSES_ROOT\CLSID\{##}\VersionIndependentProgID]
@=”$$”

[HKEY_CLASSES_ROOT\TypeLib\{%%}]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0]
@=”$$ 1.0 Type Library”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0\win32]
@=”[TARGETDIR]**.arx”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\FLAGS]
@=”0″

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\HELPDIR]
@=”[TARGETDIR]“

It’s really not that complicated for a single module. The work can be tedious to create all the values for multiple modules in scenarios where you support multiple AutoCAD and/or Bricscad versions or platforms, but these values typically don’t change over the life of the project, so it only needs to be done once. Once you have created the registry values manually, disable all other forms of COM server registration such as wizard-generated runtime registration or automatic “self-registration” at install time. A bonus side effect of the manual registration approach is that a normal uninstall reliably removes all traces of the COM server registration.