It’s been more than a year since John Cottrell of BusinessCraft sent me his vim configuration files for Synergy/DE syntax highlighting. Today I finally got around to looking at them. Despite John’s apologies, they seem pretty complete.

I’ve tested them on both Unix (FreeBSD) and Windows (7). John apparently developed them on the OS/X, so it should work there, too. See the README for installation. Please use the Issue tracker or leave a comment here about any issues you encounter. Happy vimming, and many thanks to John!

I’ve written before (PDF) about the unique event model of the Synergy/DE UI Toolkit. For historical reasons, these events are often called “menu entries,” and even though they are handled in a synchronous, delayed manner you can’t have more than one such event pending at any given time. This didn’t cause too many problems back in the old days when they were almost limited to user-initiated events. But now that they’ve also become a standard means for converting asynchronous system-level events into synchronous Toolkit events, the need to generate more than one at a time has become something much more than academic.

Consider, for instance, an input field that needs to perform non-trivial processing at three points: when it is modified, when it is displayed, and when focus leaves the field. Each of these events can be hooked to a “method” routine, but if those routines need to do anything involving user interaction, then on Windows it needs to be deferred to the outer loop by means of passing an event to M_SIGNAL. Why? Because in an asychronous callback, the UI Toolkit can’t process Windows messages, so the user will not see any changes to the UI until after that event has been handled and the routine returns. Non-Windows platforms like Unix and OpenVMS don’t have that problem, but if your code is portable to Windows then you probably want to write it that way anyway.

Now, when the user types something in the field and then advances to the next field (via Tab, etc.), all three of those events will fire: first the “change” event, then the “display” event (to display the reformatted value after validation), then the “leave” event. All three associated methods will be called in that order. If each of them signals a menu entry event, then only the last one will be seen.

I’ve added a class to my Synthesis library to extend menu-entry signaling to maintain a queue of pending events. To make use of it, you replace M_SIGNAL with multi_signal. In the outer routine that consumes events, you change M_SIGNAL(…, D_REMOVE) (or testing g_select and g_entnam, after the older form), with a loop of calls to multi_remove, until it returns ^null. Each non-null return value will be a string containing an event that was signaled, in the order in which they were signaled.

To ease the transition, I’ve made multisignal somewhat compatible with M_SIGNAL. If the consuming code isn’t changed to the new paradigm, then it will still see the most recent event — whether it was passed to M_SIGNAL or multisignal.

See the test program (test_multisignal.dbl in the tests subdirectory) for an example of how to solve the scenario I related above.

With this feature, I’m putting a lid on Synthesis version 2.2.1. Any further changes will go in the next version.

I recently started brewing beer again, after a 13 year hiatus. Now that my first batch has been in the bottle for a couple of weeks, and my second batch is fermenting, I decided I should label my bottles to keep the batches straight. I found some removable bottle labels at OnlineLabels.com, which I ordered and received.

Next came the question of how to print them? Back in the old days, I would painstakingly copy/paste/align each label in Microsoft Paint for every batch. There had to be an easier way.

I took a look at Microsoft Publisher, which appears to have the necessary options, but for some reason they just don’t work.

Then it occurred to me: why not write a little program using the Synergy/DE Windows Print API (which I helped design, after all)? I designed a command-line interface for specifying the origin, size, and spacing of the labels; as well as an image to print on them, optional outline (for testing alignment), and print preview. Implementation and testing took about an hour. ‘Tis a thing of beauty.

And so is the design for the labels for my first batch:

In case you’re wondering about the name — when I brewed my very first batch of beer in May of 1994, it was a nut brown ale. It turned out so good that I decided that was a good place to start for round 2. The good folks at Olympic Brewing Supplies provided an easy kit to get me back in the saddle. It isn’t my finest creation, but it’s a good bit nicer than anything you can buy in a store. Maybe I’m biased.

Anyway, I created a batch file to align for these labels, and I’ve included it as an example of usage. You still have to add the -image (or -outline for testing) and -n switches, but the spacing and sizing are all worked out for you.

Unfortunately, this program will only work on Windows platforms, because it makes use of the Windows Print API.

One of the most important features about the (new since version 9) object-oriented syntax in Synergy/DE is that it’s not a purist’s OOP. You can mix object-oriented and imperative programming at will. Thus, if you want to start using object-orientation in a decades-old application, you don’t have to rewrite a large portion of your existing code in order to do so.

However, not all existing code is well-suited to adding objects. In particular, existing routines that expect an argument of a primitive type (alpha, decimal, integer) cannot be passed an object instead. Since Synergy/DE supports boxing of primitives, you could go and change the type of each such parameter to object (@*), but then you’d have to go and change every place where those routines are called in order to box the existing primitive parameters. That could become a huge effort, and for the majority of cases it would add an unnecessary performance penalty.

In the case of the optional method data arguments passed through UI Toolkit routines to callback methods, Synergy/DE introduced a new parameter type, “any”. You can pass either an object or a primitive to an “any” parameter, but in a routine that accesses it in any way other than to pass it on, the parameter must be declared with a compatible type for the object passed. A good example of this would be a selection list that you’d like to load from an ls. In order to get a reference to the ls through to the load method, you can pass it as an optional argument to l_process. In the load method for that list, declare the corresponding argument as type @ls, and you can then use it.

But what if you do your list processing within a wrapper routine, so you don’t have control over the argument list? One way to attach data to a list is via the l_user routine, which stores or retrieves a record associated with the list for user-defined purposes. You can’t store an object (like an ls) in that record — Synergy/DE does not support that kind of serialization. What you need instead is a way to convert the object reference into a primitive type that you can then use later on to restore the reference. That’s the purpose of a new class I just added to the Synthesis library: Oi, which stands for Object-integer.

For any object, you can call Oi.o2i, passing the object, and retrieve a unique integer that only refers to that object. if you call it more than once for the same object, you’ll get the same integer (unless you drop it in between). To reverse the operation, pass the integer to Oi.i2o, and you’ll get back the object reference.

Naturally, this involves maintaining a reference to each object so registered within Oi. Thus, when you’re all done with an object, call Oi.drop and pass it either the object reference or its integer value, and that object will no longer be tracked.

Using Oi, you can therefore pass an integer around to any place that needs an object reference, without having to deal with the difficulties of passing an object. Obviously, a cleaner approach would be to change an API here or there, or store object references as properties of other objects. But the evolution of large systems doesn’t always lend itself to a proper redesign in order to get from point A to point B. Oi is intended to help you along your migration path, not to become a permanent solution or a recommended practice.

Synergex will soon release Synergy/DE version 9.5, which includes a released version of Synergy for the .NET Framework. In preparation for this event, I have modified the Synthesis library to be fully compatible with the released version of 9.5. You can download it at the links below.

One late-breaking (double entendre alert) surprise in Synergy.NET involves class fields that are primitive .NET types, such as “int”. If class members having these types are not enclosed in a record (aka, “loose”), then you may not pass them as arguments to any of the built-in Synergy/DE subroutines or functions, because the runtime cannot pin them properly (resulting in all sorts of unpredictable memory access havoc). The easy fix for this is to enclose member fields within a member record. You can also use Synergy/DE types instead of .NET types (for instance, i4 instead of int), but it’s sometimes hard to tell what types the compiler will translate into .NET types. If you fail to catch one of these, the compiler should provide a “loose int” error to help you round up these promiscuous bitties.

Simultaneously, I purchased a Synergy/DE for Linux license and installed it on my FreeBSD 8.1-STABLE system using the Linux kernel module and the Fedora 10 port (ports/emulators/linux_base-f10). I still don’t have terminal input or termcap working right, but everything else seems to work, so that was enough for testing Synthesis. Rather than buying PVCS Configuration Builder for Unix, I translated the PVCS makefiles into standard Unix Makefiles, and those are now included in the distribution. I also made minor changes to the sources for compatibility with either Unix/Linux or make.

Third, I decided to move the archives for Synthesis to Mercurial on BitBucket and remove the PVCS archives from the distribution. This makes the distribution much smaller. If you need access to older versions, just contact me. I’ve also provided a tarball distribution in addition to the traditional ZIP format. Here are all those links:

Now that I’ve been using XMonad as my window manager on FreeBSD for a while, I find that when I have to work on Windows one of the more painful aspects thereof is, ironically, window management. I spend way too much time hunting for the right window or arranging windows so I can clearly see all the ones I need at once. Windows Vista and 7 have the ability to view windows side-by-side or stacked, but that’s not adequate to my needs and it virtually requires using the mouse. I desperately want an automatic tiling window manager like XMonad.

So, I created the next best thing: a command-line utility that will arrange all the windows in a tiled fashion, according to a pattern specified per monitor. In the download below you will find all the sources, plus in the Release subdirectory I’ve included an executable built with Visual Studio 2010.

For usage, type ’tile’ at a command prompt without arguments. But, to give you some examples:

tile 1 2

This tiles both the primary and second monitors using a column-based scheme, with no maximum of columns. Each display will be divided into the number of columns needed to hold all of the windows on that monitor.

tile 1:2r 2:3c

This tiles the primary monitor into 2 rows, with each row split as evenly as possible to accomodate all of the windows. Thus, if the primary window contains three windows, the first window will occupy the entire top row, and the second row will be split between the other two windows. On monitor #2, we’ll have three columns — so if we have five windows there, we’ll get one window in the first column and two windows stacked in each of the two remaining columns.

If you specify more rows or columns than there are windows on that monitor, it’s automatically reduced to the number of windows. Tile silently ignores most errors, such as specifying a monitor that doesn’t exist. Tile does not affect windows that are maximized or minimized. In order to be considered within a monitor, at least 10 pixels of the window in both directions must intersect the monitor’s rectangle.

As noted above, all parts of an argument except for the monitor number are optional. If omitted, the max defaults to 99, and row/column defaults to column.

So, now I can choose my optimal layout, put it in a little batch file named ‘t.bat’, and whenever I need my windows to snap into place I can just type ‘t’ at a command prompt.

Glynis Lyttle recently asked on the synergy-l mailing list about how to change the appearance of the drill buttons on Synergy/DE UI Toolkit input windows.  These are buttons that are placed to the right of an input field if it has a drill method (IDRILL_METHOD).  They’re always sized to the width of a vertical scroll bar, and contain the text “…” as show below:

Usually, these buttons are used to launch some sort of lookup function that will populate the field.  But Glynis has multiple uses for these buttons, and would like a way to indicate the distinction between launching the calendar control for a date field versus launching a new email to the address contained in an email address field.

The Synergy UI Toolkit does not provide a documented way to do this, but it can be achieved without resorting to any undocumented functionality.

The download below includes a new function named set_drill_text, which has the following syntax:

%set_drill_text(wndid, field, text) => success

where

• wndid is the ID of the input window
• field is either the name or the index of the input field whose drill button will be modified
• text is the new text for the button
• success is returned true if successful, false if not

The text of the button will be changed to the right-trimmed value of text, and the button will be resized appropriately.  The height of the button will not be changed, but its width will be set to the width of the text plus the width of two 3D edges as described by the current theme.  For example:

The function can fail for a number of reasons:

• wndid is not a valid input window ID
• field is not the name of a field in the window or a numeric value within the range of 1 to the number of fields
• the drill button for the field has not yet been created.  Either I_FRAMES or I_INPUT must have been previously called for an input set that contains the field.
• probably something else I haven’t thought of.

Note:  whenever the input set controls are recreated, the drill button text and size revert to their original form until you call this function again.  Input set controls are recreated whenever you switch the active input set for I_INPUT/I_FRAMES, or call I_INPFLD, as well as some cases of I_FLDMOD for that field.

It would be nice to be able to change the button to display an image instead of text.  Unfortunately, that’s quite a bit more involved and would require some non-Synergy/DE code (probably C or C++) to subclass the button’s WM_PAINT handler.  We’ll leave that as an exercise for another day.

A commenter going by Anonymous Coward (I bet that’s not his real name, and I beg forgiveness if the masculine pronoun doesn’t apply) provided a solution to the double-spaced output problem users occasionally experienced with my tee utility for Windows.

Naturally, this issue occurred because of the inconsistent usage of carriage-returns and linefeeds to terminate lines of text, combined with Console::ReadLine’s interpretation thereof.  The solution, simply enough, was to use BinaryReader for input, and BinaryWriter for output, so no interpretation or translation of the characters would occur.

Like most good programmers, once he had inserted hands in the code, Anonymous Coward couldn’t leave this one alone.  He coded up several more features and emailed them to me.  I made a few corrections and included the new version here.

New features include:

• Duplicated file names are silently ignored, rather than causing a file open conflict.
• /? or –help displays usage information.
• -i or –ignore ignores cancel (Ctrl+C), instead of always ignoring it.
• -f optionally marks the end of switches and interprets all remaining arguments as filenames.

Thanks, Anonymous Coward – whoever you are!

I can’t believe that it’s been more than two months since I unleashed the Synthesis library on the unsuspecting Synergy/DE world.  I promised then to enhance it further, so herewith I announce the arrival of Synthesis 2.0, which you can download via the link below.  I bumped the primary version number because this version involves numerous changes throughout, and some significant new features.  See the full change log here.

Synergy/DE Version 9.3.1

Synthesis 2.0 is fully compatible with Synergy/DE version 9.3.1.  Unfortunately, I was unable to maintain compatibility with earlier versions of Synergy/DE, so don’t upgrade Synthesis until you’re ready to upgrade Synergy/DE as well.

Synergy.NET beta

Synergy/DE 9.3.1 also includes a beta version of Synergy.NET (Synergy/DE for the .NET Framework) on 32-bit Windows platforms.  Synthesis 2.0 includes limited compatibility with this version as well.  See the Known Issues for what’s missing.  You can also search the code for DOTNET_BETA_WORKAROUND to see the code that I expect to support in the future versus what I’m doing now.

Code Coverage analysis

Synthesis 2.0 includes two new utilities for analyzing code coverage:  cover and htmlcover.  These are command-line utilities that can be run with either dbr or dbs.  The only difference between them is the format of their output – cover writes tab-delimited data to stdout, while htmlcover writes an HTML-formatted report to a file.

Both utilities sample code execution by driving a debug session of the executable and stepping a line at a time through the code.  For this purpose, they use the Synergy/DE remote debugger, which operates over Telnet.  Thus, I added classes to Synthesis to support the Telnet protocol and sockets.

You can sample the code coverage for any Synergy/DE executable (except for .NET, because the Telnet debugger isn’t supported there).  I’ve added a ‘coverage’ dependency to the makefile in the tests directory to generate HTML reports for each of the Synthesis tests into the coverage subdirectory.  I didn’t include those in the download because of their size, but you can generate them with a ‘build coverage’ in the tests directory, if you have PVCS Configuration Builder and you’re patient enough to wait for them (especially test_regex).  They’ve already revealed some areas where I need to beef up my tests.

For more information about how this works, see the CodeCoverage class.

Bug fixes

In several places, the comparison operators used for alphanumeric did not distinguish between strings of unequal length that match up to the lesser length (e.g., “bug” == “bugger”).  That’s been corrected.

I fixed two issues related to Regular Expressions:

1. You may now enclose a begin-line or end-line anchor within parentheses.  Previously, they could only occur as the very first or last character in the pattern, respectively.  Now, for example,

   R$('/(^front|or_not)/')

   will correctly find “front” at the beginning of the line, or “or_not” anywhere.  Likewise for a $ anchor.

2. Certain complex nested sub-expressions had a bug that prevented them from ever matching.

For the future

I still have much more to add to this library.  Here are some of the things on my list:

• Improved .NET compatibility
• Additional Regex features (full Perl 5 syntax)
• More methods for ls (inject/fold, etc.)
• Prevent multiple evaluation of assertion arguments when formatting a message
• … and more.

Is there anything you’d like to see added?

How could something so simple turn into something so complicated?

One of my most popular (perhaps the most popular) post on this site is my tee utility for Windows.  I wrote it back in 2003 using the Visual Studio vintage of the same year.  Rather than including stdio.h and writing it in good old plain vanilla C code, I decided to employ the then-new managed extensions for C++ so it could <scare-quotes> benefit from </scare-quotes> the .NET Framework 1.1.  That’s where my troubles were begotten – but it took a while for them to gestate.

The first problem I encountered was trying to run it from a network share.  Microsoft, in a truly dramatic performance of security theater, decided to treat network shares as “Intranet Zone” and untrusted by default.  Sure, there were ways to establish a trusted zone, but it was a pain to remember.  Thankfully, they’ve solved that one for me.

Then recently, user Alex Armstrong noticed a few anomalies when using tee with ping.  He likes to use ping –t to repeat until interrupted, at which point ping prints out its statistics and then stops.  But when ping was piped to tee, Ctrl+C would interrupt tee instead – which closed the pipe and killed ping before it could relieve itself of its statistics.  Not only that, but since tee’s output files were not flushed, some of the output that had already been displayed on the console would not make it to the file(s).

I tried setting the Console property TreatControlCAsInput to true, but when the input stream is a pipe that caused tee to go into la-la land.  Reading further, I found the CancelKeyPress event – but for some reason I couldn’t get it to compile with the old syntax that I had used back in 2003.  With a little research, I found that the only reason why the compiler was tolerating most of my code was because the project upgrade wizard had added the /clr:oldSyntax switch when upgrading to VS2008.  When I removed that switch, all hell broke loose.  How could they change the syntax for writing managed code in C++ so drastically?  This little utility, which is only about 35 lines of real code, required changes on 15 of those lines.  Yes, they were mostly trivial – but how annoying.  It’s not the same language.  Yes, it’s probably better syntax, but it’s not the same language.

One change I would have liked to make is to use List<T>.ForEach to iterate through the list, rather than a for loop.  But I couldn’t find any way to write the Action code inline until lambdas arrive in VS2010.  Now that’s a syntax change I could get excited about.

Long story short, canceling the CancelKeyPress event (is that a double negative?) worked — Ctrl+C is now seen by ping, which prints out its statistics and closes the pipe, which stops tee normally.  If you should ever need to interrupt tee itself, use Ctrl+Break.

One more thing (as Columbo says) – Alex also noticed that ping’s output is double-spaced when piped through tee.  That’s because ping ends each line with a double carriage-return.  Console::ReadLine treats each of those as a terminator.  I don’t know why the command prompt window doesn’t have an issue with that, but I do.  I can’t just ignore zero-length lines, because then I’d lose spacing from other programs that don’t use a double carriage-return.  Any ideas?  This is supposed to be simple.

There’s nothing particularly magical about this tip, but its solution stumped me for a while so perhaps it will help out some other poor developer who is madly googling for an answer.

An MFC application needs to determine whether the path entered by a user is a valid folder.  The user already has to be an Administrator, so we don’t care about privileges.  All we want to know is, does this folder exist and is it indeed a folder and not a file or something else?

The MFC Way of doing this is to call CFile::GetStatus on the path, which fills in a CFileStatus structure and returns TRUE or FALSE.  The CFileStatus structure contains an m_attribute member that has bit values for whether its a folder, a file, etc.  This works fine most of the time.  But occasionally, calling it on the root folder of a device (e.g., “C:\”) will return FALSE.  The user reported that it failed only when the application was started from a command prompt instead of the Start menu.  That elicited from me a great big “Huh?”

Digging into it, I found that the problem reproduced when running from some command prompts, but not others.  From a command prompt where it normally failed, it wouldn’t fail if I started Visual Studio from that same prompt to debug it.  Thus, I resorted to the dreaded MessageBox debugging methodology.

I also googled this problem, found that others had run across it as well, but didn’t come up with any good solution.  One commenter suggested using SHGetFileInfo, which seemed to solve the problem until I realized that it also returned normally for folders that don’t exist.

I looked through the MFC sources and found that while the instance method for CFile::GetStatus simply uses GetFileAttributes, the static method that I was using does a FindFirstFile instead.  So I changed my application to call GetFileAttributes directly, and that works exactly as I would have expected.  It returns INVALID_FILE_ATTRIBUTES if the file or folder does not exist, and it returns a bit value that includes FILE_ATTRIBUTE_FOLDER if it is a folder of any kind (including a root folder).

GetFileAttributes provides a better solution anyway.  CFile::GetStatus just adds a bunch of extra code I didn’t need – even if I had used the instance version instead (which probably would also work).  The lesson here is that in an MFC application, it’s not always optimal to cling to MFC methods.  Take the blinders off and use the Win32 API when that provides precisely what you need.

I often check my referrer logs to see how people found my site.  Chip’s Tips gets the vast majority of its traffic from search engines.  Sometimes I’ll see a search that didn’t quite reach its intended result, and that will inspire a new post.

Quite often I see “ruby tee windows” or something similar, which leads people to my tee utility for Windows.  That seems fair enough, except that it isn’t written in Ruby.  It’s written in C#, which means that it has 12 source files and the “real” code requires 29 lines.  Furthermore, since it’s a .NET executable, it won’t run if it’s installed in a folder that isn’t “trusted”.  Talk about red tape.

Besides, this application is trivial with a capital TRIV in Ruby, using the ‘shell’ library.  Heedless of its impact on page load time, I’m including the entire source file right here:

require 'shell'
Shell.new.tee(ARGV[0]) < STDIN > STDOUT

Save that to tee.rb, and then you can perform the canonical basic test:

echo hello world | tee.rb "hello.txt"

See “hello” echoed to the console, and check out the contents of hello.txt.  Naturally, this utility is far more useful for trapping the log of a long build procedure or some other process that generates tons of output, but which you’d like to see echoed to the console at the same time.

Of course, you could also do the whole thing at the command line:

echo hello | ruby -e "require 'shell';Shell.new.tee('hello.txt') < STDIN > STDOUT"

But I like having it saved in a file so I don’t have to remember it.  This should also work just fine on *nix systems, but heck you’ve got the native tee there.

On Windows, Synergy/DE provides access to the mouse cursor via the WP_CURSOR subfunction of W_PROC. Because this API is purely imperative, managing a wait cursor properly becomes a recurring problem in non-trivial applications. Typically, it begins like this (in pseudo-code):

set wait cursor
do lengthy process
clear wait cursor

But what happens if “do lengthy process” throws an exception that’s caught outside this code? You’ll skip right over “clear wait cursor” and leave the user unable to click anything. What you’d like to do is more like this:

begin
  set wait cursor
  do lengthy process
end

… and have the cursor reset whenever and however you exit the code block.

The downloadable code below demonstrates how to do this with the new object syntax in Synergy/DE version 9. The WaitCursor class sets the wait cursor in its constructor and resets it in its destructor. So you can code it like this:

begin
  data wait, @*, new WaitCursor()
  do lengthy process
end

The data statement declares a variable that has the scope of its containing begin-end block. The variable wait is declared as an object (@*). We could have more precisely declared it as @WaitCursor, but that’s just more typing (pun intended). It’s initial value is returned by the “new” expression, creating a new WaitCursor object. This invokes its constructor, setting the wait cursor. When wait goes out of scope, the last reference to the object is lost, and the destructor is invoked and the cursor is reset — no matter how you get out of the code block. If you want to preserve the cursor instead, you can just pass a reference to the object out of the block in another variable, and clear that variable when you no longer want the wait cursor.

But what happens if you have nested operations that, agnostic of each other, each want to set a wait cursor? When the inner one finishes, it will reset the cursor to normal. That’s not what you want at all. I solved this by adding a static counter to the class, so we only reset the cursor if our count of active WaitCursor objects gets back to zero.

Of course it’s possible that other code is manipulating the cursor without using our class. That could definitely interfere with our scheme, and should be avoided if possible. One common case is the set of message box routines in the UI Toolkit (U_MESSAGE, U_MSGBOX, U_WAIT). These routines always reset the cursor to the normal pointer so the user can use the mouse to click the buttons. If you want to have the cursor go back to what it was before these routines were called, then you’ll probably need to wrap them in your own version that saves off the current cursor state, calls the original, and then restores the cursor.

As an independent consultant who bills by the hour, I have to keep track of how much time I spend on projects for different clients.  When various emergencies arise, that can get pretty confusing to reconstruct at the end of the day.  I needed an easy way to monitor my time with just a few mouse clicks.  So a few years ago I created the simple stopwatch application that you can download below.  One click to start, another to stop.  You can enter a description, and previously entered descriptions are remembered in a dropdown.  You can run multiple instances to keep track of time for multiple clients.  At the end of the day, you’ve got a total for each.

I wrote this as a C# Windows application using Visual Studio 2003.  Converting it for VS 2005 introduced a challenge, because accessing a control from another thread (the timer’s) is now considered unsafe and throws an exception.  So as you’ll see in the SetText method, I adopted a work-around from the MSDN documentation.

Back when I wrote this application, the code seemed quite concise.  Now that I’m older and wiser and have been exposed to Ruby, I can’t get over how verbose it is.  I can’t help but think that to do the same thing in JavaScript would be pretty trivial.  Maybe I’ll give it a go one day.

UPDATE 11/10/2008:  Here’s the JavaScript version.

When an array is passed to a function or subroutine in Synergy/DE, the number of dimensions must be declared in the subroutine — but the size of each dimension may not be specified.  Not knowing where the edge of a dimension lies can easily lead you to step off the garden path and over the cliff known as “Segmentation violation”.  Let’s not go there.

Synergy/DE version 9 adds a handy function, ^argdim, that lets you obtain the size of an array dimension.  You pass it the argument number (starting at 1 — you can use ^argnum(name) to obtain that if you don’t feel like counting) and the dimension number (again, starting at 1 for the left-most dimension), and it returns the number of elements in that dimension.

If you’re still stuck on a pre-9 version of Synergy/DE, do not despair.  The downloadable code below contains a function, %get_dim (in getdim.dbl), which does the same thing (except you pass it the argument name instead of the number).  Get_dim achieves this magic by declaring the array parameter as a ^val address of a descriptor.  When an argument is normally passed to a function, what really gets placed on the stack is a pointer to a descriptor that, um, describes the argument.  The descriptor contains information about type, size, address of the data itself, and several other things including dimension information.  If you look at the code you’ll probably notice that the dimension info is not all that straightforward.  For one thing, on OpenVMS Synergy/DE uses a native descriptor, so the information is stored completely differently than on other platforms.  That difference is conditionally compiled in the function, which works on UNIX, Windows, and OpenVMS.

The other file included, tdim.dbl, is a test routine for our function.  It also uses conditional compilation to employ ^argdim if we’re on version 9 or later, and %get_dim otherwise.  If you’re planning to use this in production code that’s cross-version, I would recommend putting that .ifdef block into an include file, and using the macro instead of calling %get_dim or ^argdim directly.

Working remotely via VPN on a big project presents some challenges, not the least of which is keeping your local source files up to date with the thousands of version control archives. Running a script to check all of the remote archives against your local sources can take a lot of time and bandwidth. Yet, if you don’t stay up to date, how will you know if your changes will be compatible with the latest version? You’d really like to know exactly which archives have been modified and just check those against your local copies.

One such project I work on uses PVCS for version control. PVCS writes a log file for all modifications to the archives. Each entry in the log contains the name of the archive file (full path), the person who made the modification, the date, time, and nature of the modification — all comma-delimited. So, I wrote a handy little Ruby script (which you can download below) to read the log, looking for updates on or after a specified date. For those it finds, it spawns a PVCS ‘get’ command using -u (update only if more recent) and -n (answer ‘n’ to any prompts, such as “a writable version exists, overwrite?”).

Even if you don’t have a need for such a script yourself, you might find some interesting features of Ruby in this example. Or, if you’re a better Rubyist than I, maybe you could show me how to make this script even more elegant.

The archives are stored in a directory structure that mirrors the source file directory structure on the local machine. Development occurs on both *nix and Windows workstations, so the root of the archive path in the log may be ‘/usr/archive’ or a drive letter mapped over Samba. Thus, we must strip off any of these archive path prefixes, and then add our local source root, in order to know where each source file needs to go.

To avoid duplication of effort, we use a hash keyed on the full archive path (with root prefix stripped). The corresponding value in the hash is an array containing the archive directory and the filename.

See the comments within the script for further information and usage instructions.

Quite frequently, sometimes several times a day, a Google search for something like “launch application by file extension” or “shellexecute” will bring the errant searcher to this post, which describes how to do just exactly that — in Synergy/DE. Unfortunately, most of these seekers of wisdom usually add “C#” or “ruby” to their queries.

I hate to see people land on my site and not get the answer they’re looking for. So lets give them something to find, shall we?

No need to create a C# example because there’s a great one over on The Code Project.

However, a good Ruby example eluded my search, so I whipped one up. You can download it below. As you might expect, it creates a Win32API object for the necessary linkage to ShellExecute in shell32.dll, then calls it to launch the associated application for whatever file and verb you pass. Naturally, this only works on Microsoft Windows platforms.

Dan Desch of Harland Financial Solutions pointed out a bug in my June 2001 post on checked menu entries in Synergy/DE. Synergy/DE has no built-in function to trim leading spaces from a string, so I had used the following snippet:

        while (.not. text(1:1))

          text = text(2,^size(text))        ;Trim leading spaces

which works fine so long as text contains at least one non-space character. Most menu entries fall into that category, except for those created by the “.BLANK” script command. In that case, this code goes into an infinite loop, because the overlay move blank extends to the length of the field, so you end up with exactly what you had to begin with.

Dan’s proposed solution was to branch around this logic if the entire field was blank, but I took this opportunity to optimize this code a bit. After all, performing iterative overlay moves of the entire field by one character doesn’t really jingle my elegance bells. So I replaced it with this algorithm:

        for ptr2 from 1 thru %trimz(text) ;For trimmed length

          if (text(ptr2:1))   ;Search for non-blank                   

             exitloop

        if (ptr2 .gt. 1)

          text = text(ptr2,^size(text)) ;Trim leading spaces

Synergy/DE optimizes the “for” statement such that %trimz is only executed once to get the right-trimmed length. If the field is all blank %trimz returns 0, so we’ll just exit the loop with ptr2 set to 1.

Now no matter how many leading spaces the field contains, we will do a maximum of 1 overlay move of the data. If the field contains no leading spaces (by far the majority of cases) then we’ve only executed one iteration of the for loop and the two if’s.

Naturally, if you have a need to do this sort of thing regularly, you could write your own function using this logic, and instead of moving the data over, just return the left-trimmed portion, else return the original, like so:

        for ptr2 from 1 thru %trimz(text) ;For trimmed length

          if (text(ptr2:1))   ;Search for non-blank

            exitloop

        if (ptr2 .gt. 1)

          freturn text(ptr2,^size(text)) ;Trim leading spaces
        freturn text

You can download the corrected version at the original post.

On Windows platforms, Synergy/DE lists provide three different ways to handle a mouse double-click:

1. By default, a RETURN is simulated (thus selecting the item, when using L_SELECT).
2. You can register a list double-click method in the listclass, or by using L_METHOD with D_LDBLCLK.
3. You can include a UWNDEVENTS_METHOD for double-click in a method set provided to L_METHOD with D_LWNDEVENT.

But what if you just want to suppress any action on double-click? The downloadable code below shows you how. The example includes a subroutine to modify the style of the window class to disable or enable double-clicks. Note, however, that because this style is included in the window class rather than the window itself, the change affects ALL Listbox windows in the entire application (thanks, Microsoft). So, a good practice is to change the style for the smallest possible duration, and then change it back.

Note also that this technique does not work with the ActiveX list, although a similar technique could be used (hint: the Spread window is a grandchild of the container, and its class name changes with each major version). UPDATE: I modified this code to work for ActiveX lists as well (just for you, Glynis). Note that on the next major version of Spread, the class name used (“SPR32A70_SpreadSheet”) will no doubt change. Also, when you call this routine for an ActiveX list, the double-click suppression will apply to not only all ActiveX lists in your application, but also to any Spread controls you may be using.

The example also includes code that requires Synergy/DE version 8.3 or higher.

In Synergy/DE on Windows, the colors applied to some parts of your application are determined by the Windows registry, rather than by renditions settings in Synergy/DE. This means that most of the time a user can figure out how to control a given component’s rendition by looking in Windows Control Panel or the Synergy Control Panel.

Not so for disabled fields. Windows does not provide a visual means for altering the “gray text” rendition, and it forces that rendition on all disabled fields. There is literally no way around it, short of subclassing the display for edit controls. With the default background color being a darker gray, the text of disabled fields can be difficult to read, which has caused some frustration for Synergy/DE users and developers.

All Windows colors can be programmatically manipulated via the user32.dll function “SetSysColors”. The download below demonstrates how to modify the COLOR_GRAYTEXT system color to whatever color you would like. Note, however, that after you change that color, the change takes effect for ALL applications from this point forward for the current user. So, wield this weapon with care.

Blogged about this here.