As to the "locking up," your environment is probably the issue:
- You must install RoboHelp on a local machine, as a user with full admin rights.
- To be edited, your RoboHelp projects must be on your local machine (only store them on a server for backup). They should reside as close to C: as possible, and never under My Documents.
As to the "other user" .htm files:
- How are they being produced? If they are Microsoft-based files (.doc, .xls, etc.) and are being converted to .htm, that might create problems.
- Are you copying them to your project folder on your local machine before importing them? That's usually best.
I've been here 2 years doing the same thing and this just started happening about 2 months ago. RoboHelp is installed on my hard drive at the location C:\Program Files
As far as the other users: They are in India and they upload .htm files to a specific directory in something called the "Vault" where all files are sotred (dev. included). We check them out, modify them, and check them back in at the end of the day. The next morning when I check to see if there are any modified/new files from them, I will update my local project and "import" any new files. My RoboHelp (.xpj) project stays on my hard drive but the .htm files in it are tied to the vault.
I do not remember doing anything different to cause this issue. I can edit the files in the RoboHelp project, but when I go to import it locks up immediately. The Task Manager says that it is "running" when I thought it would say "not responding".
I did notice that when I go to modify a file in Robohelp, it is read-only and I have to make it writable in order to modify it. I'm not sure how they bacame read-only files. That is different in the last couple of months.
Either the "others" are doing something different, or your IT peeps (here and/or there) are doing something different. Things rarely "just start[ed] happening," such as files becoming read-only.
I suspect that perhaps the IT folks have introduced some strange processes into the environment. For example, the "Vault" might be a "virtual network," or some other network-like environment that messes with the Access database that RoboHelp uses to keep track of all its project elements.
Another point: you're not trying to import output files from them instead of source files, are you? They, and you, may be unaware that this is unacceptable.
When you say you check out and check in the files, are you all using a source control product? If so, the projects, and that product, might not be setup properly.
You might have to acquire a good Diff product to run comparisons and then only replace changed content, instead of continually importing files over and over.
I have one other person, in India, that uses the same files I do. The procedures he follows each day are below:
1. Start the Vault and get the latest version of updated files, if any. I use the default settings.
2. For updating any file, I import the source file from the working directory to the RoboHelp project.
3. Generate the output and then replace the source and generated help files in the respective working folders.
4. The check-out and check-in process in the Vault.
He is using the same version of RoboHelp that I am and we've been working together for almost 2 years. He does not have any trouble with importing files and I didn't have any trouble until @ 2 months ago. I would think if the IT department did anything differently, my India counterpart would be having the same issues. All the files in the working directory of the Vault were read-only. I just went in and made them writable. This did not resolve the issue.
I feel I'm in desperate need of some RoboHelp training.
Your use of "The Vault" would seem to most certainly describe some form of a Source Control system. Source Control systems offer a combination between a Librarian and a Traffic Cop. Typically you log into these systems with a user ID and a password. That way the system knows who you are.
Typically with these systems the data resides on a coroporate network. And also typically you will have a "working folder" on your hard drive where the files exist. When everything is checked into the Source Control system, the files on your hard drive are flagged as "Read Only".
When you need to work with a file, you perform a process of checking out. The Source Control system then changes the Read Only status of the file on your hard drive to Read/Write. But it also makes a note of the date/time stamp. If the file stored in Source Control is newer than the counterpart on your hard drive, it copies the newer file to your hard drive before allowing you to make changes.
I'd begin with a simple sanity check. Create a totally separate and new project. Add a topic or three. Add an image. Generate. Do things work okay? If not, you have some form of issue with RoboHelp that needs to be resolved before you attempt to troubleshoot what is happening with your project in Source Control.
Perhaps try copying the content from Source control to a different folder and see if you are then able to make edits.
Hopefully something here either helped directly or sparked a thought that does.
Helpful and Handy Links
You say: "He does not have any trouble with importing files and I didn't have any trouble until @ 2 months ago. I would think if the IT department did anything differently, my India counterpart would be having the same issues."
Think about that a bit more, instead of shooting down every suggestion provided to you so far. What makes you so certain that your environment and your counterpart's environment are exactly the same, and that your IT peeps didn't mess up somewhere? What makes you so certain that some cosmic RoboHelp failure is the reason that this situation "just started happening"?
- I'd seriously inquire whether the IT peeps changed some of the settings in your use of SourceGear Vault.
- Was a new anti-virus software introduced (or the old one upgraded or re-configured), and is it wreaking havoc with your RoboHelp files?
- The other issue I would look at is your earlier comment about "where all files are sotred[sic] (dev. included)." I would strenuously object to any source control solution that is designed for storing both development code and your help source files. That can only end badly.
- Another issue is that there are at least 4 RH project files that should not be included in the source control environment: .cpd, .hhp, .ldb, .pss. Check on that.
- As to the "read-only" issue, a file in source control is always read-only until it is "checked out" (or whatever terminology SourceGear uses for that function), at which time it becomes writeable.
The thing that continues to confuse me is your use of "importing" files that have been added/edited by your counterpart (and apparently vice versa). If such a file has been added/edited within the RoboHelp project at his location, and subsequently checked in to the Vault, why aren't you just checking it out (into your local version of the RoboHelp project) at your end?
First of all, I have not been shooting down anything that has been suggested to me so far. And I resent you saying that. I have tried everything you and others have suggested. I have uninstalled RoboHelp and reinstalled it on the C: drive. We do not have a local IT department and I have a email out to the IT department on the east coast and have not heard anything back. I checked with my counterparts in India to find out what he has done differently, how he performs the SourceGear vault process, and the versions of software he is using. I am trying to see if he has similar issues.
One thing that you mentioned is that the files are read-only until it is checked out at which time it becomes writable. Mine don't become writable. In my project they are read-only and I have to make them writable to modify them. (Do you know ho to make them writable in RoboHelp/)
Another thing you mentioned is the 4 RH project files that should not be included in the source control document. I have noticed lately when I go to upload modified files to the vault that a .cpd file has been modified but it won't let me merge it. Do I delete these four types of files in my project as well as in the vault or does RoboHelp need any of them to operate properly.
Your last comment/suggestoin. My manager wants me to keep the complete updated project with source files on my local machine as a security measure. The India technical writers have a quick turnover. So, when he creates a new file and adds it to the vault, I with check it out and it gets docnloaded to my computer. I then have to import the new file into my RoboHelp project to make sure that I have all the files in it. This also puts the file in my project so that it is there when I make modificaitons and generate them. I do not put a copy of the RoboHelp project in the vault. Development does not use the source files in the product builds, but uses the generated files.
I maintain all the releases with massive numbers of .htm files. I have never had any training on RoboHelp or SourceGear (although I've repeatedly asked) vault so I am trying to learn and do the best that I can.
Thanks for your help!
- Your India guy creates a new file, and adds it to the Vault, but not within a RoboHelp project?
- Does your India guy add a source file or output file to the Vault?
- You then check out the file directly to your project folder, or some other location on your computer?
- You then open the RH project and try to import the file, and RH freezes?
- Why would you delete those four files in your project as well as in the vault? I thought the RH project wasn't in the Vault? (Those files are machine-specific; that's why they don't belong in source control.)
Resent this or not, but it appears that your organization has developed a process that doesn't seem to conform to best practices for either RoboHelp or any common source control product. Once you've collected the information you've requested from your IT peeps and your India guy, try to spell out for us an exact progression from India to you.
What normally happens is this:
- The RoboHelp project gets added to source control from within RoboHelp (it knows what files not to add), probably from your end.
- Users set the local path on their computers to match the source control folder.
- Users open the project in RoboHelp, check out/edit/check in files.
- Other users open the project in RoboHelp, check out/edit/check in files.
At no time should it be necessary to import files, uninstall/reinstall RoboHelp, manually make files writeable, etc.
I was reading your post and something caught my eye because I had a similar thing happen to me. We use a system called Documentum (sounds very similar to what you are using) and what was happening was the person checking out the document on the other end wasn't actually saving it to his hard drive even though the document was "checked out" of the library. We never did figure it out completely, but we now have a rule in place that after you check out a document, you have to do a File/Save As into a work directory. You don't have the change the file name, you just have to know it's truly open on your computer. Then when you are finished and you check it back in.
Also, the other thing that occurred to me is it sounds like it could be a "permissions" issue. If it started going wanky 2 months ago, perhaps something else changed on the back end which you may not be aware of. Network patches and upgrades to servers can change things in your working environment and you may not even know about it. I know at my company, they've been consolidating servers and while there is not supposed to be any effect on the backend, because it's simply a different server and not identical to the original server, something could be different than your original working environment.
Just some food for though. Good luck