This content has been marked as final. Show 18 replies
I've been running into the same type of problem. I've been trying to work around it but I haven't had time to update my second machine to run the application I'm developing, hence I can only run it on Win 2003 Server, which is even worst as the security is tighter (that's what I think). I would suggest that you try the following:
- Go to Tools / Internet Options / Security on the IE
- Select "Trusted Sites"
- Add the URL of the help system on the trusted sites
- Allow full ActiveX activity in the custom level
I haven't been able to figure this out yet but I have to keep trying. Hope this helps,
I don't think you can add a location on the hard disk where Axel wants to install it.
The only way I know to avoid this problem on a local drive is to allow Active X to run in IE's advanced settings but that will apply to all files and that is something your client will not allow. The correct form of help for a local PC is a CHM file. Could you not use that?
Alejandro and Peter,
thanks both for your suggestions. Peter you're right about your comment on Alejandro's post but using CHM files is not an option in my case either. I've developed and presented the whole thing with a nice skin using the client's corporate identity and there is no chance now going back to the rather bleak looks of the Microsoft HTML Help standard window.
Any other ideas? As I mentioned another option (less elegant though) would be to have a welcome screen that tells the user to "click here" to start the application. Clicking that link would start the application and at the same time allow the active-X just as if you allow it via right-clicking on the warning message. Is that possible and how could one approach that?
I don't think your idea can be made to work as the whole point is to make things more secure. If it was that easy to by-pass, every hacker in the world would be doing just that.
To the best of my knowledge, nobody has succeeded in making the mark of the web work with RoboHelp so your only solutions are:
1] Persuading the client they have to enable Active X on all their PCs. Good luck with that.
2] Using some other tool where the mark of the web will work. That means you will have lost your skins, toc and toolbar. Not really what you want.
Unless someone else has any ideas, it sounds like you have painted yourself into a corner. You are trying to use webhelp in a way which increased security prevents.
One possiblity is would your client consider Firefox as the default browser. I don't think this is an issue with that browser. However, there are other issues with Firefox as you will see if you look on my site. Click here. Which set of problems do you prefer?
That is not so good news. I'll see what we can do...
If you do find a workaround, do let us know but be ready for Bill to close it down!
I guess Bill wouldn't like it and I don't even wanna think about Steve Ballmer getting angry...
The thing is that this is my first project with Robohelp and I'm still learning. To explain briefly why things are as they are: The tool I'm working on is a help for people traveling with laptops. Among other things it will help to sort out connection issues. Therefore you need the tool on the client side not on the server. My customer will push updates onto the machines of his employees while they are connected to the VPN. We didn't consider MS WebHelp because the interface is rather awful or lets say it is what you expect from MS. We didn't really consider Flash Help yet but I'm working on it and it looks good. It seems to be the solution. At least it works on my machine. I'll try to test it with my customer today.
Thanks for the great support.
FlashHelp could well be the solution, sorry I didn't think of it. Come on you Flash guys, where were you?
If the FlashHelp does give a problem, you can insert the mark of the web in that.
Hi Peter and all
I think that the most recent version of FlashHelp already includes MOTW.
Things to watch for:
FlashHelp may break if the user upgrades to version 8 of the player. Click here for more information on this
I believe I saw something saying that this would be installed on laptops. Otherwise, why not plop it on a server at the client location? Might be worth a shot.
If there are no context sensitive calls, which is doubtful, you might want to try sticking the skinned WebHelp system inside a simple .CHM container. You do this by creating a very simple .CHM file that serves as only a shell. Then add all WebHelp files as baggage. The end result is that you get a single distributable file in .CHM format that is skinned. However, I think the Index may have issues working correctly. FlashHelp this way seems fine.
Just some random thoughts.. Rick
Hey team -
The Mark of the Web allows your page to run on your desktop without I.E.6's security message about running active content.
Fact is, using it doesn't actually let a page RUN any better, as it disables any dynamic page functionality completely. zip. nada.
You'll notice your Web pages work fine from a server; they just can't fiddle with files from your desktop.
So, how to get around it? I like Ricks' idea of Flashhelp in a .chm frame. That could be veery sweeet. Otherwise, you could compile it into an ebook. Both E-ditor and WebCompiler2 compile WebHelp systems quite nicely. Or, if you are Flash savvy, you could build a Flash front end, and you could just evoke the .swf file.
I'd opt for the FlashHelp in an HtmlHelp wrapper first. Then try ebooks if it doesn't work out.
What parts of WebHelp are considered ActiveX controls?
We have another project already deployed on the intranet that does not bring up the ActiveX message when it is invoked from field-level calls. I am almost 100% certain this is developed using WebHelp, and not FlashHelp. How can this project not invoke the IE nag message when called, but mine does when I open it locally?
The nag is only applicable when the webhelp is on a local machine, I guess that if run from there an Active X do some harm. When run from the intranet your PC is protected in other ways so the nag screen is not required.
Whew. Thanks for the response. I tested my intranet copy instead of the local copy I usually preview, and you're right, it works fine from there.
We updated to the new IE feature yesterday, and when I saw this issue, I thought it might affect the behavior of my help project in deployment. I assumed it would happen to the users too, so I have been looking for workarounds, but apparently I'm the only one who'll have this problem. I can live with that.
This new IE feature really does remove some flexibility of WebHelp deployment though. Now it's a huge pain to use for offline help systems. Useless for offline deployment, in my opinion, because the nag screen is unacceptable for users. If they're looking for help, their patience is probably already being tested. Glad this project is for an online app!!
Hi Rick and Roger,
thanks for your suggestions. Rick, I've explained earlier that this has to run on laptops because an important part of the help system deals with connection issues when traveling.
"try sticking the skinned WebHelp system inside a simple .CHM container. "... sounds simple but I haven't got a clue. Sorry. I've now worked with Robohelp for half a year and I've tweaked things hear and there but I'm still kind of a newbie. And also I know a bit of HTML but I wouldn't call myself a programmer. Similarly: "Mark of the Web". Sounds great. It raises this image of a night in shining armour that could probably save me and the rest of the world. But no, sorry again, I don't know who this Mark exactly is and as Roger explains it wouldn't help either.
I think I stick with Flashhelp for the moment. It seems to do the job.
Thanks again for the great support.
It's been a while since the last post so I'm not sure if any of you are still seeing this problem. I've been battling with it for a couple of days, never having used Robohelp before, and think I cracked it.
The first thing was to do a bulk find-replace on all the html files to replace:
<!-- saved from url=(0014)about:internet -->
and add "<!-- saved from url=(0014)about:internet -->" in all the XML files after the <?xml version=....> tag.
The next problem was a pain to find, but the Robohelp API incorporated with the application actually generates a temporary html file on the fly, which then opens the help files. So, the same thing needs to be done here.
In RoboHelp_CSH.cpp there's a function "PrepareTempHtmlFile" in there we need to change:
_TCHAR szTempFileFormat = _T("<html>\r\n")
_TCHAR szTempFileFormat = _T("<!-- saved from url=(0014)about:internet -->\r\n")
And voila, you can start breathing again!
Let me know if that works for you.
I certainly don't mean to downplay any work you have done. I think it's terrific. However...
Out of curiosity, why would you be so concerned about banishing this toolbar? I mean, WebHelp output files are intended to be placed on a server. Once you place them there, your users won't encounter the information bar. It only happens if they run the WebHelp files locally. Sure, if you are planning on installing the swarm of files locally, then you would have cause for concern. But I would think if you were installing help locally, you would be using .CHM output and not WebHelp.
Just a thought... Rick
I was under the impression that the CHM files were going to be depreciated in Vista, which is why I was trying to get this to work, is this not the case?
Like I said, this was my first attempt at integrating Robohelp... I was wondering why it was proving to be such a pain! :)
Hi again Akshay
Perhaps it would help to understand a bit of the history of help systems.
Way back before Windows, there was a DOS based help system that was somewhat hypertext based. Following that, there was something called WinHelp. WinHelp used specially formatted Microsoft Word document files saved in Rich Text Format (.RTF file extension) to create a file that had a file extension of .HLP. These were "WinHelp files" and used the Windows WinHelp viewer to display the files. I think about Internet Explorer 4 and Windows 98 introduced the new HTML Help format. These files were compiled help, just like their .HLP cousins. But the base files were HTML based and not Word document based.
Windows Vista intends to deprecate the old .HLP format files. NOT the .CHM cousins. The .CHM cousins will be around for a while to come.
Hopefully that was helpful... Rick