Flare 4: Locate in Content Explorer doesn't work anymore?

[i-tietz]

I installed Flare 4 today and found the button Locate file in Content Explorer not working properly. But only in my biggest project ...
In the content explorer only the first folder is opened ... the topic is in a folder one step deeper ...

I remember having read sth like that about an older version, too. T'was my thread ... didn't have the problem then but now ...

[Marc]

Works for me. Are you sure the XML Editor pane is the active pane? Sometimes I have to click in the editor to be sure.

[i-tietz]

jep - sure.

[Richard Ferrell]

If you try a different or the sample project does it work for you?

[i-tietz]

yes it does. In fact it works fine with ANY other project ...
The only thing I did with that project was the spell check for the whole project ... maybe that destroyed sth. ?

I even threw the project away and got myself a completely new copy from the VSS db.
Remarkable: on opening the new project the same topic was open as the one that was open when I closed the old project, which I deleted then ... where did the information which topic to open come from?

p.s.: Caution - JOKE AHEAD!

flare_is_really_old.gif

[i-tietz]

Update:
I imported the project from VSS again, but in a different folder on my local drive: It works!

Where is the "cache" that I have to empty to make it work again??

[LTinker68]

Where is the "cache" that I have to empty to make it work again??

That type of info is stored in the registry, I believe. So don't proceed unless you know how to deal with the registry.

{Insert rant from RamonS here about the MS registry and MadCap using it. }

[Richard Ferrell]

The registry for any Madcap application can be deleted, The application will recreate it on the next start.

[i-tietz]

The registry for any Madcap application can be deleted, The application will recreate it on the next start.

Good idea, but: "The registry" ... a bit small that bit of information ... any more precise directions?

What about the path HKEY_CURRENT_USER\Software\MadCap Software\Flare ?

[RamonS]

{Insert rant from RamonS here about the MS registry and MadCap using it. }

Not just MadCap, any software vendor that doesn't really care about their own support staff and the customers. The registry is just a bad bad place and accessing it through the Windows API seems to be more miss than hit, especially when having restricted rights on the system. Often enough the application writes a registry key and does not receive any return message, which is the same result for "success" as well as "didn't work for a reason unknown". So when using the registry the developers really need to write the key, then immediately read it back and verify that it exists and is accurate and that the value matches. I came across several cases where the key was created fine, but the assigned value did not get stored.
Honestly, there is nothing the registry can do that an ini file cannot do as well. And support for ini files is good. Even an XML file is an option and in any case better than the registry.

[Andrew]

The registry for any Madcap application can be deleted, The application will recreate it on the next start.

Good idea, but: "The registry" ... a bit small that bit of information ... any more precise directions?

What about the path HKEY_CURRENT_USER\Software\MadCap Software\Flare ?

That's probably where it's stored, but there are several locations in the registry where Flare stores things, and even the key you pointed out contains a lot of subnodes (at least, it did in prior versions).

The path to the registry area that controls "left open" topics is this:

HKEY_CURRENT_USER\Software\MadCap Software\Flare\Projects\<project_id_number>\OpenDocuments\<document_id_number\Url

[Andrew]

Honestly, there is nothing the registry can do that an ini file cannot do as well. And support for ini files is good. Even an XML file is an option and in any case better than the registry.

I don't exactly love the registry, but there are things it does that ini files don't.

[RamonS]

True, there are advantages, but the only advantage for the end-user may be the speed since no parsing is needed. There is only a fraction of reg keys that Flare shares with other applications and the other advantages apply more to applications that are common and could make use of roaming profiles, but as we heard in the past, the roaming profiles and Flare are not without trouble. All other advantages make other people's lives easier, but are of no impact to the end-user whereas the disadvantages directly impact the user. Since it is the user using the applications and not the developers or the sysadmin I think it is clear which side should be favoured. The registry would be a great if it isn't so notoriously unreliable and unpredictable. It's like using an Access database in a voting machine.

[i-tietz]

The path to the registry area that controls "left open" topics is this:
HKEY_CURRENT_USER\Software\MadCap Software\Flare\Projects\<project_id_number>\OpenDocuments\<document_id_number\Url

Thanks Andrew, but I'm not REALLY interested in having the project start without the topic open. What I'm looking for is the bit where it's stored that locating an open topic in the content explorer doesn't work with that project anymore as long as it is stored in that particular path ...
Any MadCapper prepared to go out on a limb and let me know?

I tried even more this morning:
I deinstalled Flare 4 (and 3.1) rebooted and installed Flare 4 again. That specific project still has that faulty behavior ... suggestions anyone?

[i-tietz]

yet another update: now it works ... I don't know what exactly changed it ... but now it works ...
Seems that reinstalling helped ... or sth ...

I really am puzzled ...

[Ineffable]

I have this same issue, except I am using v3.1.0.

Any ideas? Locate content in TOC works fine, but not in Content Explorer. Wherever the focus happens to be in the Content Explorer, that folder that is highlighted just sort of lazily flashes, but it's not the folder that contains the file currently displayed.

Everything else seems to work fine. I don't feel that it would be necessary to re-install just to fix such a minor issue. And digging into the registry?! C'mon MadCap! That's like checking my transmission fluid to troubleshoot a burned out glovebox light.

[KevinDAmery]

What you need to do is make sure that the topic has the focus before clicking on the Find in Content Explorer button. If another part of the interface has the focus then the Find In function doesn't work because it doesn't know what you want to find. What I do is click in the text of the topic somewhere, then click the Find In button.

[Ineffable]

What you need to do is make sure that the topic has the focus before clicking on the Find in Content Explorer button. If another part of the interface has the focus then the Find In function doesn't work because it doesn't know what you want to find. What I do is click in the text of the topic somewhere, then click the Find In button.

I tried that, but it seems to have a limitation. If I have the focus on the containing folder that has multiple topics and I click the text to remove the focus from the containing folder, it works properly and locates the topic in the Content Explorer if it resides in the folder that contains the topic.

If I click on any other folder that does not contain the topic that I want to locate in the Content Explorer, place the cursor in the text, then click on Locate file in Content Explorer, what happens is that the folder I clicked on to take the focus off the containing folder is highlighted and the Locate in Context Explorer gets grayed out.

So does the folder containing the currently displayed topic have to be highlighted for the function to work? Seems counterintuitive because that's why you're using the feature in the first place; you have no idea where the file, let alone the containing folder, is located!

[KevinDAmery]

I haven't had a chance to get into version 4 yet (working on other stuff than product documentation these days) but in 3.1 I never had that problem. As long as I focused on the text of the topic, the button found the file no matter which folder it was in. I can't say if they broke it in 4, though.

[Richard Ferrell]

Does it happen in all projects or just this one project? Can you try it in a sample project? is the Project local or network drive?

[doc_guy]

It's not a general Flare 4 problem. It works fine in all my projects.

[dom.reed]

I've come aross an issue with the locate in content explorer button not working when you launch a topic from the Index Explorer and then click the button. Other than that, the locate button seems to work - don't know if that helps any one narrow it down at all?