• Print

Author Topic: The GuiTools Framework  (Read 5573 times)

keybonicplague

  • Sr. Member
  • ****
  • Posts: 272
  • Keepin' it gangsta.
Re: The GuiTools Framework
« Reply #15 on: January 31, 2016, 06:47:24 pm »
Quote from: RhoSigma on January 31, 2016, 06:18:17 pm
OK, i've found that version in the forum, installed it and did try the GuiTools demo. Of course i got the c++ compilation error. As command line compiling didn't gave any information, i went into the temp folder and executed the recompile.bat (real name is somewhat different) and so i got my info. The error happens when compiling the contents of GuiAppFrame.h which provides the mutual exclusion Win API calls needed for GuiTools. These functions work with types called HANDLE, which are for whatever reason are defined as void* in the 64bit version of the compiler, while it is something different in 32bit (SDL and GL). The thing is some type casting done in the functions does not work with void*, as you can't cast void to something specific in C++.

However, you can edit that recompile.bat, deleting the -Wfatal-errors switch from the g++ command line and instead insert -fpermissive, then save it and execute it again, then it works. But well, you force the compiler here to ignore/switch off some essential safety checks, so it is not considered a good idea.

As summary, the x64 build is probably working well, as long as you don't throw in your own .h files.

BTW - Trying my FSRemapTests.bas from the QB64GiTools\storage folder, the x64 build was a bit slower than the x32 build. For comparing:

SDL x32 - time/pixel 600ns
GL   x32 -                 630ns
GL   x64 -                 680ns

Wow. Now that is what you call troubleshooting.  :D
Thank you and remember folks, Jesus saves but George Nelson withdraws!!!

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #16 on: February 01, 2016, 12:30:54 am »
Quote from: keybonicplague on January 31, 2016, 06:47:24 pm
Wow. Now that is what you call troubleshooting.  :D

Well, those things are relative easy to track, what i hate is hour long tweaking to find things which don't give any errors, but nevertheless don't work equally under SDL and GL.

eg. the first version of my input loop was something like this:

Code: [Select]
SUB GetInput()
WHILE _MOUSEINPUT
    'handle input here
WEND
END SUB

this SUB was 5x less responsive under GL than under SDL, guess why...
it was, because GL generates approx. 5x more mouse input events per second than SDL, hence the WHILE/WEND loop took 5x as long under GL

revision:
Code: [Select]
SUB GetInput()
WHILE _MOUSEINPUT
    mi%=_MOUSEINPUT 'in each loop "eat" the mouse events, which are more in GL
    mi%=_MOUSEINPUT
    mi%=_MOUSEINPUT
    mi%=_MOUSEINPUT
    'handle input here
WEND
END SUB

well, throwing away some mouse events, caused me thinking why not throw away all of em, just handling the most recent one, so revision #2:

Code: [Select]
SUB GetInput()
mi%=_MOUSEINPUT: WHILE _MOUSEINPUT: WEND
IF mi% THEN
    'handle input here
END IF
END SUB

so this works equally under both now, SDL and GL...

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #17 on: February 01, 2016, 06:32:42 am »
Quote
These functions work with types called HANDLE, which are for whatever reason are defined as void* in the 64bit version of the compiler, while it is something different in 32bit (SDL and GL).

Here i was wrong, after checking the HANDLE definition in winnt.h it's clear, that it is defined as void* (pointer to void) in both 32 and 64 bit versions. But the real difference is, that a pointer is 32 bits long in the 32 bit environment, while it is 64 bits long in the 64 bit environment. Hence, the cast i make in the functions (int32) HANDLE will try to store a 64 bits long pointer into a 32 bits long integer, which obviously doesn't fit, that's why the compiler does panic on that cast ;)

Now i will try to cast it to a 64 bit integer, and use an _INTEGER64 on the QB64 language level. Hopefully this will not break it under the 32 bit versions, as a 32 bits long pointer should easily fit into a 64 bit integer, i'll post the result here later.

SMcNeill

  • Moderator
  • Hero Member
  • *****
  • Posts: 6248
Re: The GuiTools Framework
« Reply #18 on: February 01, 2016, 06:48:24 am »
Quote from: RhoSigma on February 01, 2016, 06:32:42 am
Quote
These functions work with types called HANDLE, which are for whatever reason are defined as void* in the 64bit version of the compiler, while it is something different in 32bit (SDL and GL).

Here i was wrong, after checking the HANDLE definition in winnt.h it's clear, that it is defined as void* (pointer to void) in both 32 and 64 bit versions. But the real difference is, that a pointer is 32 bits long in the 32 bit environment, while it is 64 bits long in the 64 bit environment. Hence, the cast i make in the functions (int32) HANDLE will try to store a 64 bits long pointer into a 32 bits long integer, which obviously doesn't fit, that's why the compiler does panic on that cast ;)

Now i will try to cast it to a 64 bit integer, and use an _INTEGER64 on the QB64 language level. Hopefully this will not break it under the 32 bit versions, as a 32 bits long pointer should easily fit into a 64 bit integer, i'll post the result here later.

You may want to set a toggle to use the proper library.  In c, you could use a #if statement in the .h file, or in QB64 you could use the $IF precompiler for independent declare library calls.  ;)
http://bit.ly/Color32BI -- A set of color CONST for use in 32 bit mode, as a BI library.

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #19 on: February 01, 2016, 07:10:38 am »
Quote from: SMcNeill on February 01, 2016, 06:48:24 am
You may want to set a toggle to use the proper library.  In c, you could use a #if statement in the .h file, or in QB64 you could use the $IF precompiler for independent declare library calls.  ;)

Something like that was on my mind:

in C++
Code: [Select]
if (sizeof(HANDLE) == 4) return (int32) HANDLE ....
else return (int64) HANDLE ...

However, the use of the $IF precompiler is no option, as i wanna keep everything compatible for the SDL version too, which does not have the precompiler. So i'll will try the 64 bit cast in general, if it doesn't work the way as expected, then there is certainly another solution, that's the nice thing about coding 8)

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #20 on: February 01, 2016, 01:54:20 pm »
Updated the download in the initial post to v0.1a,

- now supporting both GL versions, x32 and x64, properly
- minor change in folder structure, palette images moved to sub-folder
- added another palette (spectrum)
- _PALETTECOLOR definitions moved out to .bi files for easy exchange

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #21 on: April 10, 2016, 10:04:17 am »
Updated the download in the initial post to v0.1b,

didn't had much time to improve on my GuiTools Framework during the past couple weeks, but nevertheless here is a minor update. It's not really much new, but mainly preparations for the next two classes i'm about to implement for image and symbol handling.

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #22 on: October 29, 2016, 02:44:10 pm »
Updated the download in the initial post to v0.2,
but you can also use the GuiTools download link right below in my signature.

After a busy summer i finally had the chance to improve on my GuiTools Framework during the past 4-5 weeks. There are two whole new object classes, one for image handling and the other one provides free scalable polygon based symbols like tapedeck icons, checkmark, arrows etc., the collection of symbols will certainly grow in the future. More than that, the pager, button and text classes were enhanced so that they can take an object of the new image/symbol classes into its own object imagery. Also some minor changes "under the hood" were required to implement the new classes smoothly into the whole Framework concept.

enjoy,
RhoSigma

TempodiBasic

  • Hero Member
  • *****
  • Posts: 600
Re: The GuiTools Framework
« Reply #23 on: October 31, 2016, 02:53:15 pm »
Hi RhoSigma

I find your tool vey interesting... but I have got some troubles in compiling and running GuiDemoGL.bas
In the topic I have compiled without error if I put QB64GuiTools folder in QB64 folder.
After loading the .exe program it sometimes  freezes and I must use TaskManager to shutdown it, any times program flows showing feedback, but it shows messages but no message in Right Button stage area.
Keyboard showed in the bottom panels are not responsive, by click on Disable button it lasts  panell disabled and a Window_box appears crashing the application!

I'm using Windows 10 , QB64 versione 20160902

I'll wish that this post has a good feedback for you
FOR eachProblem% = 1 TO Max%
    IF NOT solution%(EachProblem%) THEN
         goto Solved
    ELSE
       PRINT "Solution in coming"
   END IF
NEXT
Solved:
PRINT "Smile!"

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #24 on: November 01, 2016, 03:27:13 am »
Hi TempodiBasic,

unfortunately i have no Windows 10 machine for testing, but most of the trouble with the GL version of QB64 i have had on other systems are the Screen related instructions, here is something you can try:

Load "DemoGuiApp-GL.bas" into the IDE, then press F2 for SUBs and choose "SetupScreen".

You find a _DELAY 0.2 in that SUB, try bigger values here (max. 1.0)

If this will not help, then comment out the following lines:

_SCREENMOVE _MIDDLE
_SCREENCLICK ......

If this still not works, then comment also:

_SCREENSHOW

Please let me know, if any of this does help.

BTW: also read "KnownIssues.txt" in the "docs" folder.

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #25 on: January 27, 2017, 06:08:54 am »
Updated the download in the initial post to v0.4,
but you can also use the GuiTools download link right below in my signature.

Many new things were implemented since v0.2 (note that v0.3 was not released), there are four new object classes:
- ModelC --- an GUI object interconnection mechanism
- CheckboxC
- ColorwheelC
- SliderC

further there are minor changes to the classes ImageC and SymbolC, for a complete list of changes see the HISTORY section in the docs\ReleaseNotes.txt file contained in the ZIP compressed folder.

Please excuse the current mess in documentation, feel free to ask me here, if you run into any trouble with "The GuiTools Framework".

enjoy,
RhoSigma
« Last Edit: January 27, 2017, 10:53:19 am by RhoSigma »

TempodiBasic

  • Hero Member
  • *****
  • Posts: 600
Re: The GuiTools Framework
« Reply #26 on: January 29, 2017, 11:33:24 am »
Hi RhoSigma

have you some other fractal images for your avatar?
I'm joking....

I want to say you only this....
your work is good and impressive!
Today I load again your original work, that I have downloaded on October 2016 and I try again to let it to work with the thinking that in case of negative experience I should try your tips for GL version....

Well, today I'm using Windows 10 and QB64ide 20161109/50.... and I can say that with this version of QB64 I have no troubles or problems  while I'm running your DemoGuiApp-GL.bas!
Something has gone in the right place in QB64 in this version to let work well your AppDemo!
Just a negative note.... messageboxes are created at the topleft border of window of demo and as soon as are put in their position....it appears like a flickering of messageboxes the first time they appear.

As soon as I find my brain I can download and try  0.4 version... and also I can go on with my projects...

Thank's to share your work
FOR eachProblem% = 1 TO Max%
    IF NOT solution%(EachProblem%) THEN
         goto Solved
    ELSE
       PRINT "Solution in coming"
   END IF
NEXT
Solved:
PRINT "Smile!"

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #27 on: January 29, 2017, 12:43:10 pm »
Quote from: TempodiBasic on January 29, 2017, 11:33:24 am
Just a negative note.... messageboxes are created at the topleft border of window of demo and as soon as are put in their position....it appears like a flickering of messageboxes the first time they appear.

Indeed, that one is driving me crazy too, but unfortunately this is a GL issue: http://www.qb64.net/forum/index.php?topic=13385.0

In the old SDL version i leave the screen (MessageBox) hidden, move it to the center in hidden state and then _SCREENSHOW it, so it opens right in place in the center position without any flickering. The GL version does for whatever reason not support screen moving while the screen is still hidden, even more frustrating is the fact, that trying to do so will in most cases crash/freeze the program and you need to kill it via the TaskManger. This is the only reason, why I must provide different versions for GL, which sucks me a lot.

Hope somebody of our QB64 developers could sort out this issue, however thanks for trying GuiTools, let me know if any other problems arise.

enjoy,
RhoSigma

TylerDarko

  • Newbie
  • *
  • Posts: 40
Re: The GuiTools Framework
« Reply #28 on: January 29, 2017, 04:54:20 pm »
Been trying to download this since the 27th. Link not working.

RhoSigma

  • Sr. Member
  • ****
  • Posts: 377
  • Out of Time !!
Re: The GuiTools Framework
« Reply #29 on: January 29, 2017, 05:43:48 pm »
Hi TylerDarko,

welcome to the QB64 community :D

I'm sorry to read that you can't download GuiTools, but I cannot find any errors in the logs of my website regarding the QB64GuiTools.zip file. The download link works for me and obviously for other people too, so far I count 19 downloads since I've released the latest version on 27th.

However, let me know your email (if you have one) and I'll be glad to send the file to you. Otherwise I can only ask you to keep trying, maybe at different daytimes.

BTW - If you don't like to write your email here, then simply write a mail to me (left side beneth my Avatar)

  • Print