Category: Technical stuff

I'm sure we have all seen this from time to time! We run our newly compiled program only to have it disappear all of a sudden for no apparent reason. We search and search and search... Finally we find, using whatever debugging methods we choose, that the program goes down when it assigns a value to a variable. Doesn't make any sense at all until we, hours later, realize that the darn variable is a REFERENCE variable! Yep, we accidentally hit the "Reference" checkbox on the column property window.

This looks all so simple and happy, doesn't it?

But there is a deadly problem lurking on that window that is so easy to overlook!

Do you see what it is?

No?

Look again!

The "Reference" checkbox!

In the past years I have probably lost more time to this than anything else and it is nobody's fault but my own!

It happens once in a while and that is the problem. If it happened every day I'd expect it, but it happens perhaps every 3 months or so.

I'm still not sure what I do to accidentally check it! The hot key for it is Alt-F and I'm very used to very quickly hit Alt-F-S to save. Years ago I found that key combination to be easier and more universal than Ctrl-S for Save so I stuck with Alt-F-S and I'm wondering if that's what I'm accidentally doing. Or maybe I accidentally click on it. Don't know.

Whatever the reason is, every so often I check the "Reference" checkbox and it's always when I'm implementing something new. So I, rather logically, assume that it is whatever new I'm adding, not that new variable I just added. After all, what in the world could go wrong when creating a simple variable? As it turns out, quite a lot can go wrong;)

So what happens when you try to assign the "July 31, 2009" date value to a reference variable? Chances are very good that the program is going to fall over in a dramatic way - no GPF, no nothing. It just disappears! It is unlikely that the value 76186 is pointing to anything useful!

It would be nice if a warning message was implemented in Clarion 7 as an option so that it would warn when the Reference checkbox was checked when creating or modifying a variable with something like: "Are you sure you want to create a Reference variable?" or "Are you sure you want to change "Loc:FromDate" into a Reference variable (&Loc:FromDate)?" It would save me some time and definitely some frustration when I accidentally check the "Reference checkbox"!

Happy bug hunting:)

Arnor Baldvinsson

Even with all the wealth of information on the internet at our fingertips, sometimes it becomes a real challenge to find a solution to what seems to be a relatively simple problem.

For some upcoming work in Build Automator I wanted to be able to send keystrokes to a program. It somehow doesn't sound all that challenging, but I have spent the better part of today trying to come up with a solution. I have read hundreds of posts on multiple forums about this and have discovered that there are far more people that ask for this solution than those that even understand the problem, let alone who can give an intelligent answer. So far I haven't found a single post that solves it, lot of posts that give a hypothetical answer that looks like it should work, but doesn't, at least not in my case.

I have been successful in sending letter keystrokes to the editor window in NotePad, but trying to send something like Alt-F or Ctrl-O completely fails. So I'm putting this on the shelf for now even though I hate walking away from this, but I can't take more time on trying to find the solution at this point. Sometimes in programming, just like in poker, you have to know when to hold them and know when to fold them!

I got the Utilities build out last night while I was babysitting SQL Server 2008 R2 install and Visual Studio 2010 install. That was an interesting experience and I will blog about it tomorrow! I need to get some work in for my clients this week and next week I will be working on our products. I will also put in some work on the Icetips website which we have been working on behind the scenes for a while. Sue is re-doing almost every single page and it will be a very welcome update to the site!

Arnor Baldvinsson

Apparently my brain kept working on the redirection problem that I blogged about yesterday as when I woke up the morning I had a good clue what the problem was: Long path names. That turned out to be at least big part of the problem. However, it was not quite that simple, it never is! I didn't have time to do a complete research into the problem and nail down everything, but here is my findings and theories.

It appears that the compiler has issues finding files if the path to them includes pathnames that are more than 8 characters long. For example:

C:\Dev\Prod\Utilities\Src

causes problems, but

C:\DEV\PROD\UTILIT~1\SRC

does not cause a problem. But like I said, that is just part of it, as:

C:\Dev\Prod\XPTheme\Src

also caused problem. Either the problem is that there were other paths in the *.INC
line that use long path names (and there were) OR the compiler didn't grasp somehow that

C:\DEV\PROD\XPTHEME\SRC

is a short path name! I'm not sure which it is and didn't have time to figure it out.

Using a macro for any part of the path fixes the problem completely. For example, I created this macro:

DEV=C:\Dev

and then used

%DEV%\Prod\Utilities\Src

and there was no problem at all. So using the macros somehow makes the IDE correctly interpret the path name and probably convert it to a short path and the compiler is happy. When I had cleaned everything up, I ended up with just two macros being defined in my C60EE.ini:

Prod=C:\Dev\Prod
Dev=C:\Dev

I also came to a final consensus on the folder structures I'm using, which seems to be working pretty well so far. The Dev folder has 3 folders now:

With the structure in place I spent most of today copying and moving files from my old structure to the new one and test compiling various projects and products in both Clarion 6.3.9053 which I use for one client project, and Clarion 6.3.9058, which I use for pretty much everything else.

So tomorrow will be the day that I convert all my editor projects to work with the new folder structure as well as my Build Automator scripts. Then I will get this on to a virtual machine and test the structure with Subversion to make sure that it holds up for the version control!

Arnor Baldvinsson

I have spent most of the last week or so getting Subversion version control and TortoiseSVN up and running on our network. I will blog about that experience later, but to cut a long story short I have come to the realization that I have to change the folder structure that I use for my projects and products. They just don't work well for version control at all!

For about 10 years or so I have used a pretty good structure, that goes something like this:

C:\Clarion\Apps\C63\Products\Automator
C:\Clarion\Apps\C63\Products\AutomatorDLL
C:\Clarion\Apps\C63\Products\Utilities
C:\Clarion\Clarion6
C:\Clarion\Shared\LibSrc\Automator
C:\Clarion\Shared\LibSrc\Utilities
C:\Clarion\Shared\Templates\Automator
C:\Clarion\Shared\Templates\Utilities
C:\Clarion\VC\Automator

Rather than being separated by products or projects, the folders are separated by over all contents, such as Apps, Shared, etc. Apps are then first separated by what version of Clarion they are being compiled in, then if they are projects (which are in-house projects), products or client projects.

The problem with this is that the separation of products is at the very lowest level of the folder structure, where as for version control, it should be as close to the top as possible so you can check out and commit the entire folder tree for all realted product or project files at the highest possible level. So I have decided on structure like this one:

C:\Clarion\Clarion6
C:\Dev\Prod\Automator\Apps\C63\Automator
C:\Dev\Prod\Automator\Apps\C63\AutomatorDLL
C:\Dev\Prod\Automator\Apps\VC\Automator
C:\Dev\Prod\Automator\Src
C:\Dev\Prod\Automator\Tpl
C:\Dev\Prod\Utilities\Apps
C:\Dev\Prod\Utilities\Src
C:\Dev\Prod\Utilities\Tpl

This way I can for example check Build Automator out at C:\Dev\Prod and it will work with everything related to that product.

This of course requires a lot of changes to all sorts of files, such as the redirection files (RED files), Build Automator scripts, Editor projects, etc. Definitely not a walk in the park and as I'm kind of feeling my way around this it's very, very different from the way I have worked for many years and the older the dog, the slower it is to pick up new tricks:)

I expected the RED file to be relatively easy, but it has proved to be one of the most challenging; for a reason I'm not yet sure of.

Clarion allows you to set up "macros" in the C60EE.INI file as shortcuts to the folders. This is done in the [Redirection Macros] section in the INI file like this:

Shared=C:\Clarion\Shared
SharedTpl=C:\Clarion\Shared\Templates
SharedImg=C:\Clarion\Shared\Images
SharedIco=C:\Clarion\Shared\Icons
SH_Automator=C:\Clarion\Shared\LibSrc\Automator
SH_Catalyst=C:\Clarion\Shared\LibSrc\Catalyst
SH_CCS=C:\Clarion\Shared\LibSrc\CCS
SH_Files=C:\Clarion\Shared\LibSrc\Filesandstuff
SH_Magic=C:\Clarion\Shared\LibSrc\Magic
SH_Other=C:\Clarion\Shared\LibSrc\Other
SH_Previewer=C:\Clarion\Shared\LibSrc\Previewer
SH_Utilities=C:\Clarion\Shared\LibSrc\Utilities
SH_Xplore=C:\Clarion\Shared\LibSrc\Xplore
SH_LibSrc=C:\Clarion\Shared\LibSrc

My corresponding Redirection file entries looked like this:

*.clw=.\Z-CLW ; .; .\CLASSFILES; %ROOT%\LIBSRC; 
  %ROOT%\3RDPARTY\LIBSRC;%SH_AUTOMATOR%; %SH_CATALYST%; 
  %SH_CCS%; %SH_FILES%; %SH_MAGIC%; %SH_OTHER%; 
  %SH_PREVIEWER%; %SH_UTILITIES%; %SH_XPLORE%;
  %SH_LibSrc%\PowerOffice

*.inc=.\Z-INC ; .\CLASSFILES; %ROOT%\LIBSRC; 
  %ROOT%\3RDPARTY\LIBSRC;%SH_AUTOMATOR%; %SH_CATALYST%; 
  %SH_CCS%; %SH_FILES%; %SH_MAGIC%; %SH_OTHER%; 
  %SH_PREVIEWER%; %SH_UTILITIES%; %SH_XPLORE%;
  %SH_LibSrc%\PowerOffice

This works great and no problems with this at all.

But what I found today was that my changes for *.clw files and *.equ files (Equate files) as well as *.trn seem to work just great, the same cannot be said for the entry for the *.inc files! Currently I have this in my new Redirection file:

*.clw=.\Z-CLW ; .; .\CLASSFILES; %ROOT%\LIBSRC; 
  %ROOT%\3RDPARTY\LIBSRC; C:\Dev\Prod\Automator\Src; 
  C:\Dev\Prod\Utilities\src; C:\Dev\Prod\Checkbf\src; 
  C:\Dev\Prod\ITMB\src; C:\Dev\Prod\ITME\src; 
  C:\Dev\Prod\ITML\src;  C:\Dev\Prod\Outlookbar\src; 
  C:\Dev\Prod\PowerToolbar\src;C:\Dev\Prod\Previewer\src; 
  C:\Dev\Prod\SQLBrowse\src; C:\Dev\Prod\Taskpanel\src; 
  C:\Dev\Prod\WinFix\src; C:\Dev\Prod\XPlore\src; 
  C:\Dev\Prod\XPTheme\src

*.inc=.\Z-INC ; .; .\CLASSFILES; %ROOT%\LIBSRC; 
  %ROOT%\3RDPARTY\LIBSRC; C:\Dev\Prod\Automator\Src; 
  C:\Dev\Prod\Utilities\src; C:\Dev\Prod\XPTheme\src

This works without any issues for the *.clw (as well as the *.equ files, which I'm not showing here) but not so for the *.inc files! The compiler simply will not find *.inc files in the Automator, Utilities and XPTheme folders (there are several more, but I'm concentrating on just those to start with).

However, if I create a macro for the C:\Dev\Prod\Automator\Src and C:\Dev\Prod\Utilities\src paths, and use that macro in the Redirection file, everything compiles without a problem! I.e.

[Redirection Macros]
BA=C:\Dev\Prod\Automator
UT=C:\Dev\Prod\Utilities

*.inc=.\Z-INC ; .; .\CLASSFILES; %ROOT%\LIBSRC; 
  %ROOT%\3RDPARTY\LIBSRC; %BA%\Src; %UT%\Src;

Since I had set up macros for all the *.inc folders last time I guess I never ran into this anomaly before, or maybe that was why I had created all those macros - just can't remember!

Bottom line is that if something weird happens in your redirection file and it doesn't seem to work, try to create a macro in the INI file and see if that helps! Note, that in order to create the macros, you MUST close the Clarion IDE! In the INI the macro does NOT include the %, i.e. BA defined in the INI becomes %BA% when used in the Redirection file.

Arnor Baldvinsson