This content has been marked as final. Show 35 replies
Welcome to the forum.
You cannot take output files and use them as source files, assuming the output is from RH. Other HTM files may be different.
Use one of the supplied sample files and publish from those.
(back them up first to keep clean copies)
So...there is no way to import .htm files from compiled RoboHelp? The system allows me to import the files (cleanly I might add), generate WebHelp or Flashhelp, and view the output. Why won't it allow you to publish the help system? Why wouldn't it just leave those specific files out?
It seems there has to be a way instead of recreating every file from scratch.
I don't understand why you would want to import output files when you already have the source.
Normally when you import an output file, you see some red squares in the file you have imported into your project.
You don't recreate every file from scratch. Your source files are permanent. Each time you update the content, you generate new output files from those source files. You don't create new source files from old output.
I think there is a fundamental misunderstanding here.
My original RoboHelp project was wiped out when my operating system crashed on my personal computer; therefore, I no longer have the project file. The client I am working for has sent me a pc and I have downloaded the trial version of RoboHelp. I created a new project and attempted to import a few .htm files from the server where I last published before my pc crashed. I deleted the red boxes at the top and bottom of the files I imported.
I opened the Customer Care project that comes with the trial version and I received the same error message when attempting to publish to the server.
Any other suggestions?
Hi, mmphillipstx and welcome.
I don't think the fact that you are using a trial should affect your publishing.
From the message text, it sounds like you are trying to publish a WebHelp or FlashHelp project to a RoboHelp Server. If that's the case, you need to choose WebHelp PRO or FlashHelp PRO as your Single Source Layout (SSL). This will present a different Publishing wizard site setup screen when you get to that part of the publishing process. The "Connection Protocol" should say "RoboHelp Server" when you click the New button.
Also, you must make sure that the RoboHelp Server version matches the version of your authoring client.
So if you are using the Trial of RoboHelp 7 you must publish to a RoboHelp Server 7 server. Otherwise, you can publish WebHelp or FlashHelp to a "regular" non-RoboHelp Server server.
Hope this helps. If not, let me know.
While I was typing, you guys were talking
I should add that my post does not address the import of output files one way or the other. To me that is a completely different issue from the possibility that you are publishing to a RoboHelp Server.
I think Peter and you have addressed this and you have separated this issue by publishing the Customer Care project.
OK so you only have the output files because of a PC crash. There is a way out although if there is any chance of retrieving any backup, go for it.
Otherwise pay a visit to RoboWizard's site.
Sorry, I hadn't seen the post about having opened Customer Care when I just posted.
I don't use the publish function so I don't know what to suggest. Presumably you can access the same target on the server using FTP.
I am not publishing to a RoboHelp Server.
I was able to successfully publish using an earlier version of RoboHelp on my personal computer -- the one that crashed 2 weeks ago. Since then I have a different laptop, am using the trial version of RoboHelp 7, and created a new project (since my old project died with my pc -- no backup). Because I am receiving the same error message when I try to publish my project or a sample project that came with the trial version, I need to know what the error messages mean.
Does anyone know what the cshdat_webhelp.htm, cshdat_robohelp.htm, or the bsscftp.txt files are used for and what would cause them to fail to be created?
Are you saying these files are missing from output in the !SSL! directory, or on a server?
I am saying that when attempting to publish ANY project via FTP to a server, I am receiving the following error messages:
Publishing has been cancelled. Failed to create file cshdat_webhelp.htm" followed by "Publishing has been cancelled. Failed to create file bsscftp.txt."
What are these files used for and why couldn't they be created?
These are used to store context sensitive help data for webhelp output. Are you using CSH?
We actually have two issues here and I think we need to separate them.
1. One is the best practice and procedure to reconstruct a RoboHelp project when a hard drive fails, etc.
2. The other is to diagnose why the FTP failed - because even when you published the Customer Care project, it didn't work. These issues may or may not be related?
The only reason I brought up the RoboHelp Server possibility (I know you're not using it) was because when I tried last night to publish a WebHelp project to my RoboHelp Server 7, I got the *identical* error message! I guess this was merely a coincidence. But it suggests some lack of communication with the server on the other end and thus my wondering if the FTP publishing wizard settings are accurate. Make sure your permissions, firewalls, etc. allow you to FTP from your PC to the server.
To narrowly answer your question about the three files you mention:
1. All three files are NOT part of your source material. Rather, they are OUTPUT files generated when you publish a project to a server. (therefore you would not import them to your project if you are trying to reconstruct it)
3. The bsscftp.txt is a control file generated during the publishing process. It is essentially a "log file" that is generated ONLY in the output of a published help system. (i.e., you won't find it in the WebHelp folder under !SSL!. You would only find it on the destination website.) I *think* it is used to keep the files "in synch" during a file comparison when you republish. The idea is that when you publish to a site, it will only send across files that are "new" in order to save time.
BTW, the bssc goes way back to the beginnings of RoboHelp. BSSC stands for Blue Sky Software Corporation. (Now you know )
Because these are OUTPUT files, generated during the publish process, it would be illogical to import them to your RoboHelp project if you are trying to reconstruct a crashed project.
I'm afraid I may not have solved any problems, but perhaps this will help you diagnose the situation better. It seems to me your first step is to create the Publishing wizard FTP site settings and publish the Customer Care project successfully to make sure that problem is solved. Then you can go back to the repair work on your post-crash reconstruction.
If I trip over something else, I'll chime in.
Thanks for the input John! You are a RoboHelp instructor...right? I believe you were my instructor when I took a RoboHelp training class in Austin about 8 years ago.
My FTP publishing settings are identical to how I published successfully in the past. The only difference is that I am using a provided computer from my employer - which may have security/firewall/admin settings keeping me from publishing...and that I'm using the trial version of RoboHelp 7 where before I was using RoboHelp X5.
Do you happen to know if these files are one of the first files to be created when you publish? It seems that the error message comes up right away...not as if some files start moving and then it comes up.
I am not creating context-sensitive help...just WebHelp...and FlashHelp.
Hey, I remember that Austin class. I lived there for 14 years and have since moved to Colorado. I still enjoy returning to teach though.
Now to the other issue. To eliminate a permission/connection problem, use an FTP client (WS-FTP or some shareware) to log onto the webserver. Since this would be outside of RH, you could validate whether this is a connection problem.
Let us know,
I worked with our Engineering department on this issue. They logged into my computer and we worked on the issue for 2 hours. They say it's not a Firewall or Network issue. We were able to successfully FTP using DOS and Windows outside of RoboHelp from this PC.
I have removed the application and re-installed...and I get the same error. I have attempted to install the trial version on another PC...but I'm getting "A problem was encountered while trying to load the trial period for Adobe RoboHelp 7". So far, I'm thinking I need to go back to RoboHelp X5.
Rats. Not that this helps but I've emailed some of my colleagues about this. Hopefully I will hear something soon.
Sorry for your problems.
What setting(s) have you tried under Connection Protocols?
Can you direct me where to check for Connection Protocols?
Here is the response from my Engineering department when I questioned some of the possibilities:
The FTP userid & password is correct. I just confirmed that by connecting via DOS. And, it has nothing to do with your permissions. We proved that yesterday by successfully performing FTP via DOS and also again via Windows. We even did a successful transfer using RoboHelp when we selected a Customers subdirectory on your laptop. Something is wrong with the root of that !SSL! folder, but I have no idea what RoboHelp does with that compile process that uses that !SSL! folder.
You need to try to get an answer to that problem on that user forum you were using. FTP works. Something is wring with RoboHelp that we can’t support. Somebody has to have had this problem in the past.
Last page of the wizard, where you define the server.
I just noticed in your Engineering Dept's response the reference to the !SSL! folder. That is simply where RH generates the local version of the webhelp.
Not everyone publishes their webhelp. Some take the content that is generated and give that to their developers who then put it on the server.
When you generate AND publish, first RH generates to wherever you define in the first page of the wizard and by default that will be to a folder under the !SSL! folder. Then RH tells you it has generated and asks if you want to View or Publish. When you publish it copies to the server the files it has generated to the !SSL! folder or wherever you have defined.
What's perplexing is that we did a successful transfer using RoboHelp when we selected a Customers subdirectory (a folder one level in from the root directory) on my laptop. Something is going wrong when the output folder is "...\!SSL!\WebHelp\index.htm" .
Create a folder
In the first field of the wizard, change the generate folder to that one.
Then generate and publish.
Let us know if that works.
Just an idea: Try eliminating the !SSL! folder. Trim the output path to <output folder>/WebHelp/index.htm and see if that will go to your server.
I created C:\RoboHelp_Generate...changed the output path in the wizard, generated and published.
Unfortunately, I received the same error message.
Just making sure: Since there is both an output folder and a publish destination (the server), does your publish destination URL have the !SSL! folder in it? If so, I would suggest taking that folder out of the destination URL and see what happens.
I'm pretty sure the publish destination has the !SSL! folder from the last time I was able to publish.
I asked Engineering to provide me another FTP location/login/password. After I clicked the publish button, it made it passed the file that was previously hosing. However, the transfer rate was .05 ....very very slow....but it did make it passed the file that was previously hanging up...until it timed out. My output folder was C:\RoboHelp_Generate\index.htm...not the usual ...!SSL!\WebHelp\index.htm.
OK, time out everybody. Now, I'm having similar problems!
mmphillipstx, I'd appreciate it if you could email me at the address in my View Profile. As I work with Tech Support directly perhaps we can consolidate our concerns without continuing to muddy up this thread.
I confess that during this thread I was so focused on addressing various questions that I had not actually tried the FTP publish process since installing RH 7. I typically publish to the RoboHelp Server or, like Peter, use a third party FTP client (out of habit).
So I set up various tests and indeed am coming up with similar error messages.
I sent a report outlining mmphillipstx's problems (and mine) to technical support. Thus, my request for you to email me directly. Sorry for all the trouble. I will report back asap. Hopefully we can clear all this up soon.
Don't know what you guys are messing about at but it works OK for me! :-)
I first set up a RH6 project so that if the issue was RH7, I would not be caught by that. Once I resolved the path issue (unique to my site), it published OK.
I then repeated the process with RH7.
Here are my settings in the hope that if you follow, all will be OK.
In the first page of the wizard I generated to the !SSL!\webhelp.
In the last page, my settings for the server were:
Connection Protocol: FTP
Host Name: http://www.grainge.org (Note HTTP)
Untick Anonymous user and enter User ID and Password
/whatever it should be
See how that goes.
My FTP settings are as follows:
Descriptive Name = Test
Connection Protocol = FTP
Host Name = ftp2.g1440.net
Port = 21
Plus the userid and password.
I had Engingeering provide me a different ftp location and userid/password. Now I'm not getting error message but it is timing out.
Just a guess
I am now able to publish via FTP using RoboHelp's WebHelp Publishing Wizard.
It turns out RH is looking for a unique FTP server instead of a "virtual directory" on a common FTP site.
Let me explain my setup. Bear with me because I'm not a "real" network guy.
I run my own small Windows 2000 Server which has about 20 websites. A few for profit, but mostly for my class work,etc.
In IIS, years ago I set up a single FTP Server (using the conventional port 21). So, with only one IP address on my server and one FTP server, how do I access 20 different website domains on my server? Well, IIS allows you to create "virtual directories" related to a single FTP server site.
This works without a hitch when I use 3rd party FTP clients (such as WS-FTP or Cute FTP, or even Windows Explorer).
However, for reasons I still don't understand, RoboHelp needs to connect to a main FTP server site, not a "virtual directory". So I created a new FTP Site using the IIS wizard. But this time I assigned it to port 2021 instead of 21.
OK, now back to RoboHelp. In the WebHelp Publish Destination dialog box I put the IP address (or domain name), user/password like before. BUT, I changed the port to 2021. In the Server Directory field, I left it blank. This did the trick and works like a charm.
So, mmphillipstx you might explain this to your Engineering folks and see if they have as much success as I did.
Sure hope so. This drove me nuts! I've been using RH since 1992 and had never really bothered using the built-in publishing feature. Now I know! BTW, this works the same for RH X5 and RH 6 as well. It's not just an RH 7 thing.
Here is the response from the Engineering department regarding the resolution:
This is a bug with RoboHelp …are there any RoboHelp updates or patches that can be downloaded.
The FTP site is, in fact a Virtual Directory. But that server FTP is shared by many clients, so we can’t set it up to be a dedicated FTP site for your purposes. Until this is fixed by RoboHelp, I can only suggest that you continue to do the FTP process that we explained last week.