Early WIP on v2.55

[Michael Lobko-Lobanovsky]

Yes Patrice,

Your patch seems to be working fine for me, thanks!


(Why aren't you ever commenting in time on my patches? Don't you like what I'm doing? )

[Patrice Terrier]

Why aren't you ever commenting in time on my patches? Don't you like what I'm doing?

Because i couldn't always test them in time, but i am so delighted of the great work that has been done on OR.
For me you are my most valuable partner, and this is the reason why i sent you pandora to show you my gratitude.

And i am always waiting for your new patches like a boy waiting for Santa 

[Patrice Terrier]

Here is a screen shot of what i have in mind for the OR help window, indeed it would be based on a listbox (on the left) to select a specific topic.

Each topic would be stored in a distinct .rtf file.

And the first Help menu item, will be used to display the control.

Does that makes sense to you?

[Michael Lobko-Lobanovsky]

AWESOME!

What about adding a very thin "paper" tint to the help pages? Snow white looks a little too high contrast against the OR dark gray background...

[Patrice Terrier]

What about adding a very thin "paper" tint to the help pages

I don't know how to change the color of an embedded OLE object (EM_SETBKGNDCOLOR doesn't work with it).

And pure white is better for WYSIWYG if ever we decide to allow the printing of a topic.

I think that the best place to display the help file is to use the full view port (GetViewRect), and above everything else, your thought?

We could use ESC to close the help view (a toast window will inform first the user what to do at the time of the help popup).

[Michael Lobko-Lobanovsky]

I don't know how to change the color of an embedded OLE object (EM_SETBKGNDCOLOR doesn't work with it).

You shouldn't. You should rather change the background color of the original .RTF file when typing it in the RTF editor.

And pure white is better for WYSIWYG if ever we decide to allow the printing of a topic.

Do you wear glasses, my friend? My eyes are crying for mercy after 30 minutes of staring into the white pages of my VS 2013. 

And I can hardly imagine anyone these days printing out the help pages on hard paper.

I think that the best place to display the help file is to use the full view port (GetViewRect), and above everything else, your thought?

No, I think the help file should be displayed against the gP.hMain background with the splitter moved full left. And certainly not above everything else, but below everything else -- the splitter, toast window, etc. The user should be able to drag the splitter and compare immediately what they are seeing in the OGL viewport with what's written and depicted in the help topic.

We could use ESC to close the help view (a toast window will inform first the user what to do at the time of the help popup).

Exactly!

[Patrice Terrier]

You should rather change the background color of the original .RTF file when typing it in the RTF editor.

I do not know how to do it with WordPad from W10 

[Michael Lobko-Lobanovsky]

Gimme the RTF file and a PNG sample of the page tint. I'll try to do the rest.


And have a good night's sleep. A new patch with a bombastic Model Slicer mod will be waiting for you in the early morning.

[Patrice Terrier]

i was able to change the background color with LibreOffice Writer, however when i display a transparent png file, the color doesn't match.

Try with the attached png, and see if you can get it to work, i did try to add an opaque background of the same gray color, but once embedded there is always a small difference with the text background.

The gray color should be RGB(204,204,204)

[Michael Lobko-Lobanovsky]

Please give me the RTF file with the PNG embedded to see what you're talking about. It is better to see once than to hear one hundred times.

Here comes the promised patch:

-- TODO menu entries hidden for the time being. They are too discouraging to see hundreds of times when debugging.
-- All texture and renderer load errors have been intercepted and handled gracefully.
-- Model Slicer is under View->Geometry Control->Slice model on X,Y,Z axes. Pretty smart to inspect the model's guts.

I'm sending many files because I was working on this patch for 48 hours and I forget which ones have been modified by me. Hopefully all of them are there in the zip.

Enjoy!

[Patrice Terrier]

Here is the requested RTF file, showing the problem.

Thanks for the patch i will download it asap!

Added
This is the first time i see such slice feature, so amazing and handy to inspect the inside!

Note: The ESC key should leave the slice mode to switch back to default mode.

[Patrice Terrier]

Except for the flickering, is that what you had in mind to display the help control?

If you agree with this, i shall send you a new patch for sync purpose, even if this Help control is still a work in progress.
I have to figure how to get rid of the richedit flickering 

Added
On this scenario we are unable to use the right scrollbar of the RTF control that becomes only visible when the splitter is moved to the full left side.
Thus i think the best solution is to quickly switch bettween the Help and the GL window (Show/Hide), and that would solve also the flickering problem.

[Michael Lobko-Lobanovsky]

Patrice,

It seems flickering is inherent in the RichEdit control due to the CS_HREDRAW | CS_VREDRAW styles. My WordPad is using RichEdit50 and still flickers like hell on resize. I can remember I used to fight a lot with RichEdit flicker probably a dozen years ago when I was developing my FBSL code highlighting control based on RichEdit20 for Eclecta (FBSL stock code editor). I don't remember if I succeeded because later, I used subclassing to totally suppress the control's native drawing and re-implemented my own absolutely flickerless text painting routine on the control's canvas that used the RichEdit metrics but drew everything in it using custom BASIC/C/Asm routines.

MS RichEdit seems to have been written by total lamers judging by its hellish flicker. No wonder every decent language developer around tends to write their own code highlighting controls for their RADs/IDEs.

Since flicker is what I'm seeing in WordPad, I'm intrinsically prepared to see it in OR without much anger or irritation as well. And yes, your video implements my vision of how the OR help system should display regardless. Have you tried to actually resize the RichEdit control while panning the slider, rather than drag it in view from beyond the right border? Resizing will ensure the right scrollbar is always visible. Another palliation is to have a custom vscroll control next to the right gray panel that's always visible and controls the scrolling of the help page instead of the RichEdit original vscroll which always remains under the right-side gray panel or is made disabled and invisible programmatically.

I'm waiting for your OR help sync patch, my friend. I prefer to face the problems  rather than read about them.

Re. your OR orb logo, be prepared to use 24-bit RGB illustrations with their backgrounds colored manually to match the page background color exactly, rather than use 32-bit ARGB's and watch the OLE color blending fail to reproduce the sRGB palette of your alpha PNG's correctly.

[ADD] Seems like WordPad's OLE/RTF uses dithering when resizing the embedded PNG objects, hence the unexpected change in colors. For all I know, it may even discard the original PNG format and save the images in some obscure lossy indexed-color BMP format, and that would be exactly what causes dithering/discoloration. I'm going to reboot into XP (that's where my MS Office is installed) and see, if the DOC/DOCX formats are better at preserving the original picture format of embedded image objects...

[Patrice Terrier]

My friend

Since my previous post, i managed to display the help file, in full view port.
Because we must keep the right side of the splitter to display the future texture editor you spoke me about.
see my comment at line 65 of Splitter.h
 ///////MoveWindow(Futur_DrawingWindow, w - gP.splitXoffset + SPLITTER_WIDTH, 0, gP.splitXoffset, h, false); // PAT: 12-23-2018

To Show/Hide the Help window, click on the top left OR icon.

The patch for syncing purpose is attached to this post.

Added
Forgot to say that you must put the attached HELP.rtf into the \Reader folder for test purpose.

[Michael Lobko-Lobanovsky]

Thanks Patrice,

While I'm investigating your patch, please consider the attached HELP_MSWORD.rtf file that has your ARGB OR orb embedded in MS Word. It displays flawlessly in Word regardless of it being in the RTF format, and the PNG is true color transparent with the [198,198,198] background preserved.

However neither WordPad nor RichText can display it correctly (BTW is your Libre Office RTF canvas ARGB-capable as is Word's?). They are obviously trying to convert ARGB to some much lower color bitness smearing the image with moire and dither dots in the process...

BTW what about HTML/PDF formats and controls? They are ARGB capable, and MS Word can translate its RTF files with embedded true color transparent objects to both HTML and PDF losslessly.