Browser Based AIR Help not displaying in browser

Has the help been moved from where you generated it to another local location?

Check the copy where you generated it. See Snippet 106 on my site. I think it is the same problem.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Hello. I just attempted to publish a current RoboHelp HTML project as Browser-based AIR help. I published directly to the network server (\\onbase.net\shares) and I get the same results - a blank index.htm page. However, when I publish to the !SSL folder locally and launch the index.htm file, the help launches with no problem. How did you work out your issue?

My first thought it that the network server to which you are publishing is not a web server. You will need to liaise with your IT people on that.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Thanks, Peter. What preparation needs to be done on a web server to accommodate browser-based AIR help?  I have been trying to find an article on it.  Can you point me to one? (I did try viewing the browser-based help in my network folder in a Firefox browser.  It complained about the flash plug-in, but when I installed it, it didn't do anything to make the help viewable.)

Hi there

If this is just a connection using a drive letter, you likely need to add the location to the "white list" for the Flash Player as described in the link below:

Click here to view

Cheers... Rick

Added the network folder to the locations in the Flash Player settings.  Still a blank screen when I open index.htm.  I will investigate with our IT department.

Your IT people will know what is required.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

I would like to suggest an ever so slight tweak to my colleague's verbiage.

Your IT people *SHOULD* know what is required.

Happy Friday all... Rick

I think some of the "SHOULD" be put on the instruction from Adobe (and me). We host many apps on our website, so if there are any specific intricacies to hosting browser-based AIR help, its up to me, Adobe, and resources I can access like this community board to figure it out. :/

Specifically - From what I am reading, all I should have to do is give IT my Browser-based AIR help folder to my IT dept. and have them point to the index.htm file. Just like WebHelp. We have all the plug-ins required.  BUT, when this is done, we get the error message "Error in accessing help fileserverbasedhelp."  I'm not sure what this message means, much less how to correct it.

I did some investigating and found an article about using the AIR APIs to launch a browser-based version of the help on their PC, as well as how to launch an install for the users.  ( http://help.adobe.com/en_US/AIR/1.5/devappshtml/WS5b3ccc516d4fbf351e63e3d118666ade46-7e15. html) But, I don't believe this is what we need.  We just need our users to VIEW the AIR browser-based help from OUR server.

I will continue to play with the other options in the AIR Output screens, like "Specify the URL for Online Help," but the instructions on Peter's site say that this is only used when generating "AIR Application and Browser based Help" as the Output Type.  (I am only trying to generate "Browser based Help."

Any assitance is appreciate.

I think that how a web server should be configured is way beyond what RoboHelp OLH can cover. Consider the number of server operating systems.

What I was getting at was that you were referring to a network server rather than a web server. On a server not configured to host web sites, you will encounter problems. If the server is a web server, then you should be OK.

http://www.grainge.org/demos/bbair/ links to some browser based air help on my site. My service provider did not have to do anything special to make it work.

I have neither seen the error message you report nor seen anyone else report it.

Is the address your customers use similar to mine? Should I be able to access it with a link?

Create a small project with a couple of topics and see if that works on your server. If it does not, send me the project output and I will put it on my site to test.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

The help was placed on a virtual machine by one of our developers.  As long as I iknow I have done what I'm supposed to with the output and the index.htm file, I will check more on the IT side about the server environment and investigate.  Hopefully, I can post a success and what I've encountered for others soon.  Thanks.

Hello again

I think if I were in your position I would try some smaller baby steps first. Create a very small help system. Perhaps it has three topics. Generate that as WebHelp. Copy to the server. Test. Does it work? If not, you know the issues are more deeply rooted in how the server is set up than anything else. At that point you toss the ball into IT's court.

If it works, try generating Web Based AIR Help and copy that to the server. Test. Does it work? If so, this would suggest it's specific to your project and not the server configuration. If not, then you have more detective work to do with your IT peeps.

Hopefully this will help some... Rick

Whoah... what happened there? I posted this about ten minutes before Peter's reply appeared!

Methinks forum gremlins may be at play...

Surely a RoboWizard can handle a gremlin?

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Is the virtual machine configured as a PC or a web server?

If as a PC then it is not going to work.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Took the suggestion and successfully published WebHelp for a smaller project. 

With great anticipation, I then tried to publish the same project with the same parameters, but this time as browser-based AIR help.  Got the problem with only being able to view a blank screen when I hit "index.htm."

I tried to publish browser-based AIR help with and without the "Server" screen also, but still go the blank screen problem.

I take that back about the Server stuff.  :/  I forgot to hit the "Publish" button when help was finished generating.  That's the good news.

The bad news is.... now I got this error...

Finished compiling Adobe AIR output in 6 sec(s)

Warning: Failed to publish to "Ian's Virtual Machine". reason: Connection failed. Please check the connection and post again.
Native Error: The server name or address could not be resolved.

I don't think anything happened to the server from the time I published all of the other cases.

Geeez.  I hate when people make me think like this on a Monday!  OK.  I can't gain access rights to the IT server.  I will configure my own PC as a server, publish the AIR help to it and see if a group of lucky contestants can hit it. Stay tuned.

Hi there

Just a comment about something I'm seeing that is a very hazardous practice depicted in your screen captures.

I see what I'm assuming to be the "test WebHelp", but in the "Output Folder and Start Page" field, I note you appear to be pointing to \\CSG... and that would appear to me that you are specifying the ultimate destination where things will end up after publishing.

Note that generating and publishing are two completely different processes. Again, perhaps this was a one off just to test things. But if you are actually working this way, be prepared for lots of issues. One of the first things that happens is that RoboHep attempts to delete all the files in the output folder before it creates the new set of files. If you are pointing to the final upload location, you could see issues as RoboHelp attempts to delete the files and "pulls the rug" out from beneath the users that may be accessing them at the time.

Some folks think they are being clever and saving a step or two by working this way, but in fact, they are causing themselves grief down the road.

Cheers... Rick

Thanks for the catch, Rick.  I was just hurrying through and wasn't looking down the road.  I will definitely keep my working directory and publish directories separate.

Browser based AIR Help has to be on a web server as I keep saying.

How can you make a PC into a web server? Sharing a drive is not the same thing.

http://www.diffen.com/difference/Application_Server_vs_Web_Server

Good luck.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

I have IIS and can create one locally.

Let us know how that goes.

I still think the quickest way to establish prove the problem is the server is to let me have the output for the test project. I can put that on my site for a short period so that only you or anyone you give the link to can access it.

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

Set up a server and web client for publishing and had a developer check it.  It is fine.  I successfully published a small project as browser-based help and had others view it via the server. Now for the bad news...

I set up a new web client (site) on the server -  in the same manner - and created a new SSL for it - in the same manner.  This SSL, however, was for my main (larger) project.  It won't publish!!!  I get the "Publsihing has been cancelled. The process cannot access the file becasue it is being used by another process." error message.  Looks like others have this problem, too.  I checked community, read the posts, and have tried the recommended remedies (rename the folder, uncheck Republish All, etc.).  Nothing works.  I've even create a new site from scratch, new application pools, etc. and that doesn't work either. 

I spent all day with this yesterday.

What happens if you publish to small project to the location you are trying to use for your main project? You have proved the small project can be published OK to one location so being able to publish it to the desired location would prove that location is capable of running browser based AIR help. If that too refuses to publish to this different location, it doesn't identify the cause but does point to the location being the issue rather than the output.

My offer to put your main help on my server just briefly enough to test it works there remains open, subject to size.

Have you tried copying the generated output to the server rather than publishing it?

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

You get  the "Publsihing has been cancelled. The process cannot access the file becasue it is being used by another process." error message if you use the same location for your Browser-based .air file "Start Page" and your server's virtual directory "Destination Path" (see pic).

I also noticed that when you create a new AIR SSL format in an existing project, RoboHelp automatically fills in the Output Locations with a file structure from the last AIR SSL you configured.  I guess this was done as a user "convenience," but in my opinion lead the user down a bad path.  Specifically, it identifies an "index.htm" file that doesn't exist yet, so to me, this tells you that an Index.htm should be used as a starting page (common to most hosted UI). So, I thought that I should be browsing to the index.htm file that I would create in the virtual directory on my web server (ie., Destination Path)...hence the error message.

Ummm, isn't your epiphany the same identical thing I told you about earlier in this thread back on Aug 13?

To put things in simpler and possibly easier to comprehend terms, here is what you have done, then discovered.

You baked a batch of cookies.

(Used RoboHelp to mix Topics, Images and whatnot to create AIR Help output)

Your cookies weren't baked using the cookie sheet. Instead, you put the dough balls right into the cookie jar and stuck the jar in the oven.

(Pointed RoboHelp output folder to the final destination and not an intermediate destination.)

You then tried to take the baked cookies and shove them into the jar they were already inside.

(RoboHelp publish options were configured to the same location as the output folder)

Cheers... Rick

Thanks for the heartfelt response.  I guess I lost sight of the Aug. 13 post while navingating all the posts on this forum, checking all the MVP websites and Adobe communities. Sorry for being so thoughtless.  But, maybe there are other ignoramuses like me out there that also go down this road and find this post direcly....and perhaps it will be helpful. Oh, and..thanks for the analogy with sexist overtones.

LOL, it was never my intent to berate you. Only to try and point out that things like this require some thinking through.

As for the "sexist overtones", those totally aren't intentional either. I facilitate RoboHelp and Captivate classes for my living. I find that as humans, we all have food in common. As a result, it is often helpful to use an analogy to better understand what is going on with things we cannot see physically, such as RoboHelp generating and publishing files.

If you look through these forums at all, you will see that I use the analogy of a Single Source Layout as being just like a recipe. The Single Source Layout Pod being just like a recipe box. And I'm always calling the SSL the "SSL Recipe". Go ahead and search. You'll be surprised.

So it had nothing to do with this post. Only that it's my preferred way of trying to help make sense of things that aren't exactly tangible.

Sorry if I offended you in any way. I certainly didn't mean to!

Cheers... Rick

No sexist overtones with Rick - everything comes back to food with him ;>)

I apologize, Rick.  Still, the post is berating. It was what lend me to that perspective. It is also what will discourage further posts. Consider your audience.  Most looking for help on a community site are not officiators and in most cases are having trouble navigating the product and/or the instructions.

Have a look at Kevin Siegel's blog post on the difference between generating and publishing -

"Adobe RoboHelp 10: Generating Versus Publishing"

http://iconlogic.blogs.com/weblog/ - it just came out in today's e-mail newsletter, so it might be a couple of days before it hits their website.

Not sure if you identified the issue with this or not. I have run into this issue before as well and my solution, while basic, has always worked on HostGator at least by simply changing the case on the following javascript file from "ac_oetags.js" to "AC_OETags.js"

I have no idea why that makes a difference but it has - every time