filename substitution

This forum is for all Flare issues not related to any of the other categories.
Post Reply
kevinmcl
Sr. Propeller Head
Posts: 252
Joined: Mon Sep 11, 2006 10:58 am

filename substitution

Post by kevinmcl »

Before Flare, I had RoboHelp for a while. I switched to Flare sometime around its first version.

Our command-line interface (yes, those still exist) has many commands that are a mix of uppercase and lowercase letters.

Some time ago, possibly even in the RH days, I found I was having problems due to topic files that were named with mixed-case.
So, I set about renaming them all with lower-case-only filenames.

Unfortunately, I kept getting these nasty error messages in my Publish output log, where a file was identified as having a problem, and then the "broken" link was shown as a full path, including topic filename, followed IMMEDIATELY by a slash and the name of another file. No space. Just the proper filespec of the offended topic, with the filename of the unsuccessfully-linked topic file, looking like this
file:///c:/docs/productname/projversion/prodhelp/Content/administration/topic01.htm/Topic02.htm

There were MANY. Over the months and years, I hunted them down and killed them in help projects for several products.
Somehow, I always seemed to overlook some. I have not had a project Publish itself without at least a few of those errors since I've had Flare. Again, I started with Flare version 1-dot-something and I'm now running 7.2.

I take RELIGIOUS, FANATICAL care to make all my filenames lowercase only, with underscores where spaces would go. Topics, graphics, snippets, whatever.... If I have a chance to name it while it's being created or handled, I ensure that it's ALL lowercase, ALL the time.

So how could I possibly keep missing some, or getting them wrong?

Today, I stumbled upon the how.

Attached is a photo of my screen, showing Flare. I had created a snippet and was plugging it into a few topics. I called up Link View, to remind me which ones I'd already done. And there it was. Look at the name of the file where I've circled it in yellow in the Content Explorer panel. Now, look at the name of the same file where I've circled it in yellow in the Link View for that new-today snippet.
2012-02-11_Flare_screw-up1.jpg
My conclusion: For years, Flare has been internally substituting. Or, when I renamed some of those early topic files - and ALWAYS said yes to the dialog that asked if I wanted to update links - Flare was preserving the old name somewhere.

I know for a fact that "hsm_showpolicies.htm" has been all lowercase for years. I went back and looked at earlier project versions.
Somewhere in its guts, Flare is remembering what that file was named in 2006. And choosing to substitute that old name for the real name. This is the first time I've had it happen where I can see it while I'm working.

I would just LO-O-O-O-O-OVE to have somebody try to explain how that's a feature.

Go ahead.

Give it a whirl. :-)

Whatever the feature is, it's existed since day one of Flare. I don't recall seeing it documented, but that's not new. They like to call things by names nobody would think to call them.

-k
PS: Since the time of RH (before switching to Flare) I started on 32-bit Windows XP, moved to 64-bit Windows XP, and last year switched to 64-bit Windows 7, always the "Pro" versions (we skipped Vista). I keep .NET up-to-date.
You do not have the required permissions to view the files attached to this post.
De gustibus non disputandum est
kevinmcl
Sr. Propeller Head
Posts: 252
Joined: Mon Sep 11, 2006 10:58 am

Re: filename substitution

Post by kevinmcl »

PPS: (replying to myself...) Has anybody else had a problem taking screencaps of Flare in action?
My photo in the first message was taken after both Windows 7 Pro "Snipping Tool" and [Ctrl][Shift][Print] captured the Flare screen with blanks in some of the frames, notably the Content Explorer and the relevant fields of Link View. Yes, those are both versions of the MS built-in screen-cap function...
De gustibus non disputandum est
RamonS
Senior Propellus Maximus
Posts: 4293
Joined: Thu Feb 02, 2006 9:29 am
Location: The Electric City

Re: filename substitution

Post by RamonS »

What were the problems with the mixed case file names? Windows doesn't care, which is probably .NET developers don't care either. Since they live in a Microsoft only world they probably never even think (or know?) about other systems where CaMeLcAsE is not the same as camelcase or CAMELCASE. Interestingly enough, as you showed there appears to be at least one developer who (accidentally? intentionally?) used a case sensitive comparison to fish out broken links (and she or he actually did it right!).
I doubt it is a feature and now that you found the how fixing it should be much easier. I recommend a bug report.
RamonS
Senior Propellus Maximus
Posts: 4293
Joined: Thu Feb 02, 2006 9:29 am
Location: The Electric City

Re: filename substitution

Post by RamonS »

kevinmcl wrote:PPS: (replying to myself...) Has anybody else had a problem taking screencaps of Flare in action?
My photo in the first message was taken after both Windows 7 Pro "Snipping Tool" and [Ctrl][Shift][Print] captured the Flare screen with blanks in some of the frames, notably the Content Explorer and the relevant fields of Link View. Yes, those are both versions of the MS built-in screen-cap function...
Hmmm, first time I tried that tool and I like it, much easier than SnagIt for mundane stuff like that. Capturing Flare worked fine for me, no blanks. My first suspicion is always outdated or too new graphics drivers, but that's just a wild guess.
kevinmcl
Sr. Propeller Head
Posts: 252
Joined: Mon Sep 11, 2006 10:58 am

Re: filename substitution

Post by kevinmcl »

Other than the problems of broken links that reported (in the output log) as those /~/~/~/filename1.htm/fileName2.htm, I don't recall what the other problems might have been. I'm sure it's back in the archive of these forums from 2007 or earlier. Or maybe it's in the RH forums from even earlier. I just remember somebody telling another person (who had a problem vaguely like something I was seeing at the time) that it might be best to use all-lowercase for filenames.

As for the bug report, I don't have instructions to replicate the problem, and I don't have the day it would take to strip down an existing real project to a size I could reasonably attach, while preserving whatever it is that makes the "feature" happen. Certainly not "on spec", anyway.


On third thought, I wonder if it's a bug or a feature that the logging utility reports those odd filespec combinations. It's probably connected somehow.

There were only a couple left in my current project, and neither one referred to the offending file "hsm_showpolicies.htm" or "hsm_showPolicies.htm" ...

Here's what one looks like in the Publish log:

Resolving links in output files...
LunaSA: Compiler: C:\Users\me\Documents\_docs\_docs_2011_2nd-half\Luna_SA\SA_5-1\SA-SP_Help\LunaSA_5-x_help\Content\reference\ckdemo_menu.htm: Resolving hyperlinks in generated file: Missing topic: file:///C:/Users/me/Documents/_docs/_docs_2011_2nd-half/Luna_SA/SA_5-1/SA-SP_Help/LunaSA_5-x_help/Content/reference/ckdemo_menu.htm/CKDemo_command_descriptions.htm

The file ckdemo_command_descriptions.htm does exist, and has for years. It's in the same subdirectory as ckdemo_menu.htm.

Another thing that might have contributed ... um.... points of concern over the years is that I've moved the projects around a few times. They lived on two different desktop/tower PCs and lately a laptop - all of which had slightly different file systems - as well as a few months where I tried to work with my source files on a network server. Each time I moved, I had to go in and fix a lot of pointers in both Project files and some topics. In every case, it was a matter of relative links not being relative enough. Problems took a while to reveal themselves after I moved back from server to desktop, since I was almost always connected to the network and that server was our primary, mapped automatically on startup... meaning that if Flare wanted to link from a project on my desktop to a Project or topic file that was still back on the server, it could, even though it should have been linked to the local-on-my-desk version. In other words, the process of moving a project was never as clean as just copying the file structure intact.
De gustibus non disputandum est
Post Reply