Author Topic: Early WIP on v2.55  (Read 908 times)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #135 on: November 08, 2018, 05:28:33 am »
No success nor new ideas so far.

Moreover, I've started to get random OR crashes due to memory access violation when the Ctrl toolwindow is on screen in a fancy mode and I try to exit the app. The debug mode lands randomly at various places of OR code but the cause is always the same -- heap memory corruption. A few times the debugger even pointed me to WinLIFT.dll as the offending module. :(

I'm too tired having spent the whole night at my desk. Going to zzzz now...
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #136 on: November 08, 2018, 10:07:05 am »
My trackbar control doesn't behave the same, because i want the thumb button to jump directly to the correct mouse location, rather than moving tick by tick from the old location to the new one.

For now, just rem out the latest tooltip trackbar addition, if you think they are causing havoc in the Ctrl toolwindow.

To display trackbar values, i prefer to use something like in the attached screen shot, and keep the tooltip for generic help, like for the other controls.

So far, for the Ctrl toolwindow, i would recommend to switch to unskinned mode and plain toolwindow (no Ctrl popup) until full completion, then i will take on it and create a state of the art "tunning" like interface for the final version.

And about the final version, many of the new commands, will be converted to overlay checkboxes rather than menu options, to be more easy to use.

The important point that has been fixed in WinLIFT is the menu misalignment problem, but i couldn't see how this could have an impact on the toolwindow.
 
« Last Edit: November 08, 2018, 10:22:32 am by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #137 on: November 08, 2018, 10:20:05 am »
Good "morning"! :D

1. So I consider TBS_TOOLTIPS fully Windows-compliant and working as expected.

2. The problem with TBS_CUSTOMTIPS still needs further investigation and that's what I'm going to continue right now.

3. The problem with random memory crashes at exit from OR that occur only if the toolwindow has already been created (i.e. the Ctrl button has been pressed at least once) will be the last to try and resolve when item 2 above has been fully fixed.

Thant's gonna be my program for today. :-\

I've read your response while typing this and I think that what you suggest would be somewhat humiliating for my intelligence. I'm sort of a d'Artagnan by my nature: I see a challenge and I attack, rather than retreat in pitiful surrender. And at any rate, there should be no faults in your frameworks otherwise there'll be no value in them when you bequeath them to your heirs and decide to pass away. :D

So I think I can spare yet one more working day trying to resolve the problems cleanly. :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #138 on: November 08, 2018, 10:29:47 am »
TBS_CUSTOMTIPS is something new (from yesterday) and i am still experiencing with it, to see if it is of real value or not, and if the new style is not causing havoc in Windows itself :o

Added:
I could turn it into property rather than adding a new Windows style, that is a MS prerogative.

« Last Edit: November 08, 2018, 10:35:55 am by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #139 on: November 08, 2018, 10:58:12 am »
Quote
... many of the new commands, will be moved to an overlay rather than menu, to be more user friendly.

In my opinion, triple nested popup menus are still user friendly enough (especially in full screen where there's no other way to use many of OR's options) while quadruple nested would be too shaky and cumbersome.

Another one of my ideas of user friendliness is having many of popup menu options duplicated in the main menu for much faster access when windowed.

Yet more user friendliness lies in being able to utilize ESC and TAB keys to the fullest. ObjReader can now ESC from the toolwindow, Z-axis rotation, full screen, and design/fancy render modes directly to the main render mode (in precisely that order) without the help of the menu. Moreover, when in a texture inspection or fancy render mode, the user can now loop through the other modes of the group (bypassing the disabled ones) with the help of TAB key, again without having to resort to the menu.

That's what I call genuine user friendliness of a GUI, my friend. And if at the same time the GUI is also a pleasure to look at, then the entire program's strong wow-factor appeals to the user to the fullest. Not every user is a pure point-and-click guy like us, you know. ::)

Quote
I could turn it into property rather than adding a new Windows style, that is a MS prerogative.

That'll be the best thing to do for all trackbars because the moment the user needs the latest thumb position value, e.g. to handle custom tooltip text for keyboard key presses, currently it isn't yet available to poll from the user code. Or we need a hypothetic skGetThumbPosition() export for genuine Windows trackbars, not only for your custom-drawn mockups. And that export must be 100% guaranteed functional and always freshly updated for trackbar keyboard control as well.
« Last Edit: November 08, 2018, 11:08:48 am by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #140 on: November 08, 2018, 11:55:14 am »
Mike

Working back on CUSTOMTIP for the new property, i found several mistakes because i have used skChild rather than the new skTip, this is what happens when i am getting too tired…
This could cause the memory allocation error you are experiencing  :-[

I shall post a new pandora with my latest changes for winmerge comparison purpose, as soon as i have got some good food :)
« Last Edit: November 08, 2018, 12:31:16 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #141 on: November 08, 2018, 12:39:35 pm »
No problem my friend, we aren't as mighty as we used to be and that's only natural. :)

Take as much time as you need to still feel fun from coding. We're in no hurry and it's our valued privilege at our age. :)

(The toolwindow's latent memory corruption seems so heavy I can't call a ChooseColor common dialog in response to the button press. The dialog crashes OR at dialog show or hide time... :'( )
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #142 on: November 08, 2018, 02:18:21 pm »
Mike

Here is the latest pandora, please do a winmerge to see the changes done to the code.

The name of the new property is
skUseCustomTip(IN HWND hWnd)

Note: when used, the TBS_TOOLTIPS style is disabled

Would you like me to send a WM_NOTIFY/TTN_NEEDTEXT from SetThumbLocation and GetThumbTrackLocation, when CustomTip is being used?

Tell me what you think?
« Last Edit: November 08, 2018, 04:03:01 pm by Michael Lobko-Lobanovsky »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #143 on: November 08, 2018, 04:02:26 pm »
DL'ed OK , now starting to merge, then will proceed with testing...

Please don't expect it to be soon. Build some nice little model for us in the meantime. :)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #144 on: November 08, 2018, 06:15:44 pm »
No Patrice,

The one and only obvious improvement is that now there seem to be no more app crashes due to memory corruption, and that is very very good! :)

SYNOPSIS
  • The TBS_TOOLTIPS style without skUseCustomTip() behaves automatically as expected in bare Windows, being responsive to both the mouse and the keyboard. Its readings polled in WM_HSCROLL with SendMessage((HWND)lParam, TBM_GETPOS, 0, 0) update correctly while the mouse hovers above, or drags, the thumb and also when the mouse hovers above the trackbar and the arrow/homing keys are pressed on the keyboard.
  • The TBS_TOOLTIPS style with skUseCustomTip() behaves like a custom tooltip text control, which means this style and this property complement each other just overriding Windows automatic readings in the tooltip with our own ones. But the problem with the keys persists exactly like it was in the old code: both the mouse and keyboard keys generate WM_HSCROLL messages but only the mouse values of thumb position are correct when polled with SendMessage(TBM_GETPOS). The thumb positions polled with this message in response to key presses appear to be one key press old: Home returns whatever was the previous position, then End returns Home position, then Home again returns End position, etc.
  • No TBS_TOOLTIPS style with skUseCustomTip() still brings the custom tooltip text on screen as in issue #2 above, which IMHO is absolutely wrong. If there's no TBS_TOOLTIP style, there should be no tooltip created at all, and consequently, neither skUseCustomTip() nor skSetCustomTipText() should have any effect whatsoever.

While issue #3 is easy to resolve, I'm seeing no progress with issue #2. We still have no means to determine the real current position of the custom-drawn thumb at all times (including WM_H/VSCROLL) by polling WinLIFT directly, rather/other than SendMessage(TBM_GETPOS). It probably goes to the trackbar too early when the thumb hasn't yet reached the new position in response to a key press, or hasn't yet updated its thumb position value.

While this nuance may not be so important for verbal/descriptive custom tooltip texts, it is absolutely essential for the accurate numeric readings of current parameter's real values.

What trackbar are you using to test your mods against? I have a feeling you're modding WinLIFT by ear following my descriptions rather than testing your mods against some real setup. My ToolWindow.h is now heavily modified as compared to what it used to be originally and I wouldn't want to incorporate it in your OR too early without my other mods.

Yet I could probably describe what minimal code you should add to your virgin ToolWindow to have a test bench to reproduce and correct issue #2 on your own machine... ???
« Last Edit: November 08, 2018, 06:31:55 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #145 on: November 08, 2018, 06:30:24 pm »
My Friend

To say the truth i have got a flu, and was coding most of the last changes with a terrible headache.

After looking again at it, it seems that
UseCustomTip should be renamed skIsCtrlUsingCustomTip and exported from the DLL.
To be able to use it with the WM_VSCROLL and WM_HSCROLL messages

Glad it has solved the memory corruption, sorry for the confusion between skChild and skTip that was my mistake :-[

Added:
Quote
What trackbar are you using to test your mods against?
The vertical straylight one  :(
...
« Last Edit: November 08, 2018, 06:35:46 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #146 on: November 08, 2018, 06:42:58 pm »
MY FRIEND,

WHY DIDN'T YOU TELL ME EARLIER YOU AREN'T FEELING WELL? :'(

This all can wait till you get better; I have other important things to do with my code, and I can live with inaccurate readings for the time being. When you tell me you're in a good shape again, I'll send you my minimal code for a virgin ToolWindow for us to be as close to the real setup as possible.

Get well soon and sorry for my being so insistent, impatient and perhaps even aggressive in the recent couple of days. :-[

Please accept my sincere apologies!
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #147 on: November 08, 2018, 07:57:01 pm »
Mike

The OR WndProc
    case WM_VSCROLL: // ML 02-01-2018: scene brightness
is incomplete, because so far it considers only the SB_THUMBPOSITION,
none of the SB_BOTTOM to SB_TOP flags are handled correctly.
https://docs.microsoft.com/en-us/windows/desktop/controls/wm-vscroll

As you said, being "point and click" guy, we never noticed the wrong value while using the keyboard arrow keys to move the slider.  :-\

Easy to solve when using SendMessage(TBM_GETPOS) rather than HIINT(wParam).

Code: [Select]
    case WM_VSCROLL: // ML 02-01-2018: scene brightness
        //zTrace(STRL(SendMessage(GetDlgItem(hWnd, IDC_BRIGHT_CONTROL), TBM_GETPOS, 0, 0)));

        //gP.rIllumFactor = (HIINT(wParam)) / -100.0f;
        hCtrl = (HWND) lParam;
        if (hCtrl == GetDlgItem(hWnd, IDC_BRIGHT_CONTROL)) {
            gP.rIllumFactor = SendMessage(hCtrl, TBM_GETPOS, 0, 0) / -100.0f;
            SCALEILLUM(0); SCALEILLUM(1); SCALEILLUM(2); SCALEILLUM(3);
            //zTrace(STRF(gP.rIllumFactor));
            if (skIsCtrlUsingCustomTip(hCtrl)) {
                swprintf_s(zTxt, strSize(zTxt), L"brightness %2.0f", gP.rIllumFactor * 100 + 0.001f);
                skSetToolTipText(hCtrl, zTxt);
            }
            gP.redraw = -1; // Redraw the OpenGL scene
        }
        break;
« Last Edit: November 08, 2018, 09:44:29 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 640
Re: Early WIP on v2.55
« Reply #148 on: November 08, 2018, 09:54:47 pm »
You're dealing with trackbars rather than scrollbars, Patrice. Prefer to use TB_xxx constants here.

And note that HIINT (HIWORD actually) isn't recommended by MSDN itself.

Note also that it's exactly SendMessage(TBM_GETPOS) that  falters in WM_HSCROLL when our trackbars have custom text tooltips and the keyboard keys are pressed. :(

Get a good rest and tell me when you're ready for the ToolWindow minimum code to reproduce the glitch.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 841
    • zapsolution
Re: Early WIP on v2.55
« Reply #149 on: November 08, 2018, 09:59:29 pm »
YEs i meant TB_rather than SB_ of course.
So far with the posted code that works well by me, using either the mouse or the keyboard, i got exactly what i want.

Added:
Quote
Get a good rest and tell me when you're ready for the ToolWindow minimum code to reproduce the glitch.
I can start looking at it tomorrow, thanks!
« Last Edit: November 08, 2018, 10:07:48 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)