Early WIP on v2.55

[Patrice Terrier]

Your demo using HH.exe doesn't work by me.

I had a com browser written long ago in PowerBASIC, in my "zap media lite" freeware, and my "zap image solution" commercial project.

However what i like with .rtf, is that everything is embedded into one single file (like .pdf), and that is what i was looking for.

[Michael Lobko-Lobanovsky]

What exactly doesn't work for you? I have tested it thoroughly on my W10 box (which has all the latest updates installed) and found no differences with my W7 environment except a better window region management that prevents those annoying grayish flicker on the left of gP.hGL that you can notice in my W7 video.

I implemented the HTML help in a separate HH.h include file that coexists peacefully in the project with your own Help.h due to a few #ifdef MLL_DEV directives. So no problem for the both of us if we don't come to a consensus.

[Patrice Terrier]

What exactly doesn't work for you?

It deosn't show anything, i have checked the Help folder and all the extra files are within the extra "THIS IS A TEST PAGE.files" subfolder.

BTW, please check the attached OleRTF written in PowerBASIC and tell me if it works by you.

[Michael Lobko-Lobanovsky]

It works but the same as with your OR RTF help system: image dither and hellish flicker on resize.

[ADD] Please check if there's a C:\Windows\hh.exe file on your machine. Also, put this texture into your \Reader subfolder:

[Patrice Terrier]

Ok i have been able to use the version you sent me, after cliking on the top left OR icon. 

The PowerBASIC version doesn't flicker by me, did you embed it changing the parent?

[Michael Lobko-Lobanovsky]

AAAAAAAAAAaaaaaaaaaa!!!!!!!!!!!!!!!!!!!!!!!1111
 

Didn't you watch the video?

[Michael Lobko-Lobanovsky]

... did you embed it changing the parent?

Assuming you're talking about HH.exe rather than your PowerBASIC demo, no, HH.exe isn't "embedded". Its window styles have been changed to remove the decorations (non-client areas) and set gP.hMain as its owner window, and then WS_EX_TOOLWINDOW was added to prevent it from showing an icon in the title bar. Finally, WM_CLOSE was sent to its tool bar to kill it and prevent it from showing the contents/index tab control. All this automatically made the browser control occupy HH's entire client area.

Then all moving/resizing was done using standard MoveWindow() calls.

HH.exe is created/destroyed each time the top left orb is clicked.

The real beauty of it is it's working identically under both W7 and W10 and it doesn't interfere with the gP.hGL display of the model in all modes.

[Michael Lobko-Lobanovsky]

The .HTM was intentionally made very rich visually using the background image to test the setup under the most stressful conditions. The background image is huge. If it's omitted and a background color is used instead, then the .FILES subfolders will be much much smaller and redraw on resize will be significantly faster.

Last but not least, if there are no images in a particular .HTM then there won't be any accompanying .FILES subfolder to it at all.

[Patrice Terrier]

Also, put this texture into your \Reader subfolder

I couldn't see any difference with the one i already have 

I am making some test with the .odt format (much smaller file size)

[Michael Lobko-Lobanovsky]

I couldn't see any difference with the one i already have 

I wasn't sure you had one named 69.png exactly. IIRC the app aborts if it fails to find the FPS texture in its \Reader folder.

My message had been edited to attach the texture before you said you finally tumbled to click the orb.

[Michael Lobko-Lobanovsky]

Now, do you want me to send you my sources?

[Patrice Terrier]

Now, do you want me to send you my sources?

I will need it for sync purpose, but as i told you i want to experiment with the ODT format (1/3 the size of a single RTF file).

[Michael Lobko-Lobanovsky]

Well, well, well... The sides are chosen, aren't they?

[Patrice Terrier]

Nothing build in concrete yet...
but i don't want to bloat OR with too much extra files, and i want to preserve smooth left right scrolling as we have it already when moving only the OGL control with the splitter.

I may have a solution using a backbuffer to suppress the flickering, with my skOFFscreen or zOFFscreen API that i could export from the existing DLL(s), and using WM_PRINT rather than WM_PAINT using subclassing or a superclass.

Added
You know what, ODT is nothing more than a standard ZIP file (xml based)…
all related files being unzipped to the temporary folder, then removed when not needed anymore 

That means we could do the same unziping first everything into the temporary folder on the fly, when switching from one topic to another.
Do you think that would work with HH, and what would be the best tool to produce the documentation itself ?

[Michael Lobko-Lobanovsky]

but i don't want to bloat OR with too much extra files

From my perspective, a single file project of such complexity is a nuisance, a rudiment of the PowerBASIC era when its so called RAD wasn't able to cope with multiple files.

And for what it's worth, I may just as well consider the RTF branch of help file system a piece of bloatware based off of technologies of the yesteryear.

... and i want to preserve smooth left right scrolling as we have it already when moving only the OGL control with the splitter.

And I want to preserve compatibility with the pre-W10 platforms, which in my opinion is a more worthwhile objective.

I may have a solution using a backbuffer to suppress the flickering, with my skOFFscreen or zOFFscreen API that i could export from the existing DLL(s), and using WM_PRINT rather than WM_PAINT using subclassing or a superclass.

We could probably suppress it with just a careful choice of timely direct gl_DrawScene() calls rather than gP.bRedraw = TRUE requests to repaint the viewport at some unknown later points in time. We can also use SendMessage(WM_SETREDRAW) wisely to update it only when the actual positions of the windows have already stabilized.

You know what, ODT is nothing more than a standard ZIP file (xml based)…
all related files being unzipped to the temporary folder, then removed when not needed anymore
That means we could do the same unziping first everything into the temporary folder on the fly, when switching from one topic to another. Do you think that would work with HH ...

This is what HH.exe does with the .CHM files, and it is damned fast at that doing it directly in memory without dumping anything on disk at all.

... and what would be the best tool to produce the documentation itself ?

The best tools for the help file system are MS Word and MS HTML Help compiler if you're following my route. If not, you may settle with Libre Office and zlib.dll unless you have your own code to include in the project to compress/decompress ZIPs, JPEGs and PNGs without any 3rd party dependencies. I have used such an include in my FBSL. It added only 8KB to the binary. Then I switched over to the 7-zip algo to yield almost twice deeper compression ratios.