PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: WinFBE 1.5.6 on GitHub (November 26, 2017)  (Read 472 times)

Paul Squires

  • Administrator
  • Master FireFly Member
  • *****
  • Posts: 8173
  • Windows 10
    • PlanetSquires Software
WinFBE 1.5.6 on GitHub (November 26, 2017)
« on: November 26, 2017, 01:53:06 PM »

Version 1.5.6 (November 26, 2017)
- Changed: Updated to use WinFBX Library Version 1.0.

https://github.com/PaulSquires/WinFBE/releases
Logged
Paul Squires
PlanetSquires Software
FireFly Visual Designer, WinFBE Editor

Pierre Bellisle

  • FireFly3 User
  • Junior FireFly Member
  • *
  • Posts: 62
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #1 on: November 27, 2017, 12:13:08 AM »

Hey Paul,

WinFBE 1.5.6 on Windows 7-64
WinFBE\Examples\WebGL\NeHe_06\WebGL_NeHe_06.bas->exe
Using WinFBx Ver 1.0 aka-> -i D:\Free\bi\Roca\WinFBx\
32bit FBc compiler works fine,
but with both FBc-64bit 1.05 and FBc-64bit 1.06, exe will GPF when clicking the {x} close button,
the Escape key to exit will work fine.
« Last Edit: November 27, 2017, 12:15:03 AM by Pierre Bellisle »
Logged

José Roca

  • FireFly3 Registered User
  • Master FireFly Member
  • *
  • Posts: 2836
    • José Roca Software
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #2 on: November 27, 2017, 01:35:28 AM »

Strange. Works fine in my computer (Windows 7).

If you have DebugView, it can be debugged by adding

#define _CAXH_DEBUG_ 1

before the includes.

Code: [Select]
00001407 6:08:57 [4736] --- CAXHOST DESTRUCTOR - BEGIN ---
00001408 6:08:57 [4736] Release IFontDisp - cRef = 0
00001409 6:08:57 [4736] --- CAXHOST DESTRUCTOR - CLOSE - BEGIN ---
00001410 6:08:57 [4736] CAxHost_IOleInPlaceFrame SetActiveObject
00001411 6:08:57 [4736] CAxHost_IOleInPlaceSite OnUIDeactivate
00001412 6:08:57 [4736] CAxHost.QueryInterface : IID_IOleControlSite
00001413 6:08:57 [4736] CAxHost_IOleControlSite constructor pAxHost = 1470752
00001414 6:08:57 [4736] CAxHost_IOleControlSite AddRef = 1
00001415 6:08:57 [4736] CAxHost_IOleControlSite Release = 0
00001416 6:08:57 [4736] ### CAxHost_IOleControlSite destructor
00001417 6:08:57 [4736] CAxHost_IOleInPlaceSite OnInPlaceDeactivate
00001418 6:08:57 [4736] CAxHost_IOleInPlaceSite Release = 0
00001419 6:08:57 [4736] ### CAxHost_IOleInPlaceSite destructor
00001420 6:08:57 [4736] CAxHost_IOleInPlaceFrame Release = 0
00001421 6:08:57 [4736] ### CAxHost_IOleInPlaceFrame destructor
00001422 6:08:57 [4736] CAxHost_IOleClientSite AddRef = 3
00001423 6:08:57 [4736] CAxHost_IDispatch Release = 0
00001424 6:08:57 [4736] ### CAxHost_IDispatch destructor
00001425 6:08:57 [4736] CAxHost_IOleClientSite Release = 2
00001426 6:08:57 [4736] --- CAXHOST DESTRUCTOR - CLOSE - END ---
00001427 6:08:57 [4736] CAxHost_IOleClientSite Release = 1
00001428 6:08:57 [4736] --- CAXHOST DESTRUCTOR - SetClientSite NULL ---
00001429 6:08:57 [4736] Release IOleInPlaceActiveObject - cRef (must be 0) = 0
00001430 6:08:57 [4736] Release IOleObject - cRef = 1
00001431 6:08:57 [4736] CAxHost_IOleClientSite Release = 0
00001432 6:08:57 [4736] ### CAxHost_IOleClientSite destructor
00001433 6:08:57 [4736] ### CAxHost_IServiceProvider destructor
00001434 6:08:57 [4736] Release OCX - cRef = 0
00001435 6:08:57 [4736] *** IDispatch = 0
00001436 6:08:57 [4736] *** IOleClientSite = 0
00001437 6:08:57 [4736] *** IOleControlSite = 0
00001438 6:08:57 [4736] *** IOleInPlaceFrame = 0
00001439 6:08:57 [4736] *** IOleInPlaceSite = 0
00001440 6:08:57 [4736] *** IServiceProvider = 0
00001441 6:08:57 [4736] *** IOleInPlaceActiveObject = 0
00001442 6:08:57 [4736] *** IOleInPlaceObject = 0
00001443 6:08:57 [4736] *** IOleObject = 0
00001444 6:08:57 [4736] *** bInPlaceActive = false
00001445 6:08:57 [4736] DESTRUCTOR CAxHost - m_bUninitOLE = true
00001446 6:08:57 [4736] --- CAXHOST DESTRUCTOR - END ---

Pierre Bellisle

  • FireFly3 User
  • Junior FireFly Member
  • *
  • Posts: 62
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #3 on: November 27, 2017, 11:55:35 AM »

Same thing this morning after a fresh reboot.
Here is 3 logs.
1) 64{x}ButtonGpf.txt -> GPF via [X] button. A messagebox after the GetMessageW WHILE/WEND will never show.
2) 64EscKeyNoGpf.txt -> Exit via Escape key, no GPF
3) 32bitAllwaysOk.txt -> Exit via [X] button, no GPF
Logged

José Roca

  • FireFly3 Registered User
  • Master FireFly Member
  • *
  • Posts: 2836
    • José Roca Software
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #4 on: November 27, 2017, 01:28:17 PM »

And the WebGL_NeHe_04 and WebGL_NeHe_05 examples work? They do the same. The only change is the jscript code. (I forgot to state that the jscript code was taken from http://learningwebgl.com/blog/?p=571 ).

The only difference that I can see in the log file for the one that is GPFing is that the web page is keeping a reference to the WebBrowser control.

Try adding this code to WndProc to see if it makes a difference:

Code: [Select]
      CASE WM_SYSCOMMAND
         ' // Capture this message and send a WM_CLOSE message
         IF (wParam AND &hFFF0) = SC_CLOSE THEN
            SendMessageW hwnd, WM_CLOSE, 0, 0
            EXIT FUNCTION
         END IF

Pierre Bellisle

  • FireFly3 User
  • Junior FireFly Member
  • *
  • Posts: 62
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #5 on: November 27, 2017, 01:55:31 PM »

Yep, the WM_CLOSE is mandatory on my machine to avoid the GPF with WebGL_NeHe_06.bas.
Tested a dozen times.

Now...
I did try WebGL_NeHe_04.bas and WebGL_NeHe_05.bas...
They both crash in 64 and both work fine in 32.
WM_CLOSE does not have any effect on the result.


I did try under Windows 10, all works fine.
I did try under Windows 8.1, all works fine.
« Last Edit: November 27, 2017, 02:25:23 PM by Pierre Bellisle »
Logged

Pierre Bellisle

  • FireFly3 User
  • Junior FireFly Member
  • *
  • Posts: 62
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #6 on: November 27, 2017, 02:55:54 PM »

At this point, it could make sense to have some others to test on their Windows 7 machine.
Mine is pretty clean, but if I'm the only one to have the problem then
it might be related to something unique and doesn't need to be investigated.
I will do some other test later if I got time...
Logged

Pierre Bellisle

  • FireFly3 User
  • Junior FireFly Member
  • *
  • Posts: 62
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #7 on: November 27, 2017, 05:28:46 PM »

OK,
I did a lil REM this and REM that to narrow down the problem.
Turns out that if I comment out "pwb.Navigate(wszPath)" in any of the three files,
I got a blank window of course but no more GPF.


Added 01: If I set the line as pwb.Navigate("about:blank") then no GPF
Added 02: If I replace Index.html with a simple html file then no GPF.
Added 03: So CWebCtx.inc/FUNCTION CWebCtx.Navigate and Index.html could be looked at...
Added 04: Narrowing a lil bit more, commented  JavaScript  <!– glMatrix-0.9.5.min.js –> in index.html stopped the GPFs.
« Last Edit: November 28, 2017, 12:00:22 AM by Pierre Bellisle »
Logged

Paul Squires

  • Administrator
  • Master FireFly Member
  • *****
  • Posts: 8173
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #8 on: November 28, 2017, 06:05:58 PM »

FYI - I'm back working on the visual designer. Hope to have something good to show for the next editor update.
Logged
Paul Squires
PlanetSquires Software
FireFly Visual Designer, WinFBE Editor

Paul Squires

  • Administrator
  • Master FireFly Member
  • *****
  • Posts: 8173
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #9 on: November 30, 2017, 09:18:40 PM »

...using Jose's WinFBX is making coding the WinFBE editor and visual designer so much easier. Unicode is easy using Jose's library.
Logged
Paul Squires
PlanetSquires Software
FireFly Visual Designer, WinFBE Editor

José Roca

  • FireFly3 Registered User
  • Master FireFly Member
  • *
  • Posts: 2836
    • José Roca Software
Re: WinFBE 1.5.6 on GitHub (November 26, 2017)
« Reply #10 on: November 30, 2017, 10:16:44 PM »

I no longer use STRING except when I need a quick way to allocate a byte buffer. Variants have also become very easy to use. Unicode is the way to go because most of the world needs it.