FLTK-C-1.3.3 for FreeBASIC
Re: FLTK C for FreeBASIC Jan 09, 2017
no, not hide the button when clicking the button
rather
hide the box when clicking the button
rather
hide the box when clicking the button
Re: FLTK C for FreeBASIC Jan 09, 2017
oh, you edited your post and I see you use:
Fl_WidgetSetUserData(btn,box)
it works but not sure how
Fl_WidgetSetUserData(btn,box)
it works but not sure how
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK C for FreeBASIC Jan 09, 2017
Fl_WidgetSet and GetUserData is a nice feature to use any pointer as private data.
If you are more familiar with FLTK you can do the most things much smaller.
Joshy
If you are more familiar with FLTK you can do the most things much smaller.
Joshy
Code: Select all
#include once "fltk-c.bi"
sub ButtonCB cdecl (byval self as Fl_widget ptr, byval box as any ptr)
Fl_WidgetHide(box)
end sub
Var win = Fl_WindowNew (800, 600, "test")
Fl_WidgetSetCallbackArg(Fl_ButtonNew(0,0,100,20,"click me"),@ButtonCB,Fl_BoxNew(0,0,100,100,"a box"))
Fl_WindowShow(win)
Fl_Run()
Re: FLTK C for FreeBASIC Jan 09, 2017
that is slick
BUT
the idea of creating buttons and boxes from within a call back is over complicated (in my opinion ).
in a large project, i can't imagine trying to decipher exactly if and where a button was created or not by having to dig through call backs.
I find the dim shared quite simple to use and i do not understand why there is any harm in using it.
perhaps i find dim shared useful because when the button is clicked it will be calling a function or sub routine that will be doing much more then just changing the properties of only one object but changing the properties of multiple objects. since this is the case, the idea of passing multiple objects via the call back statement seems to be to complicated.
BUT
the idea of creating buttons and boxes from within a call back is over complicated (in my opinion ).
in a large project, i can't imagine trying to decipher exactly if and where a button was created or not by having to dig through call backs.
I find the dim shared quite simple to use and i do not understand why there is any harm in using it.
perhaps i find dim shared useful because when the button is clicked it will be calling a function or sub routine that will be doing much more then just changing the properties of only one object but changing the properties of multiple objects. since this is the case, the idea of passing multiple objects via the call back statement seems to be to complicated.
Re: FLTK C for FreeBASIC Jan 09, 2017
ok, now i'm making progress.
the idea was to make something similar to gtk's expander widget
the key to getting the scroll and pack widgets to resize accordingly was by hiding and showing pack0:
Fl_WidgetHide(pack0)
... expand / collapse individual expanders
Fl_WidgetShow(pack0)
the idea was to make something similar to gtk's expander widget
the key to getting the scroll and pack widgets to resize accordingly was by hiding and showing pack0:
Fl_WidgetHide(pack0)
... expand / collapse individual expanders
Fl_WidgetShow(pack0)
Code: Select all
#include once "fltk-c.bi"
Declare function ButtonHandleCB cdecl (self as any ptr,event as Fl_Event) as Integer
Dim Shared As BOOLEAN showhide(4)
showhide(1)=FALSE
showhide(2)=FALSE
showhide(3)=FALSE
showhide(4)=FALSE
Dim as string label
Dim As Fl_Window Ptr win
Dim As Fl_ButtonEx Ptr btn0,btn1,btn2,btn3,btn4
Dim As Fl_Button Ptr btns1(4,44),btns2(4,44),btns3(4,44),btns4(4,44)
Dim Shared As Fl_Scroll Ptr scr0,scr1,scr2,scr3,scr4
Dim Shared As FL_Pack Ptr pack0,pack1,pack2,pack3,pack4
win = Fl_WindowNew (800, 600, "layout test")
scr0 = Fl_ScrollNew(0,0,300,600)
Fl_WidgetSetType scr0, FL_SCROLL_VERTICAL
pack0 = Fl_PackNew(0,0,270,600)
pack1 = Fl_PackNew(0,0,270,200)
btn1= Fl_ButtonExNew(0,0,50,30,"expander1")
Fl_ButtonExSetHandleCB btn1,@ButtonHandleCB
scr1 = Fl_ScrollNew(0,0,50,200)
Fl_WidgetSetType scr1, FL_SCROLL_VERTICAL
For x as integer = 0 to 4
For y as integer = 0 to 44
label = "1"
btns1(x,y) = Fl_ButtonNew(x*50,y*50,45,45)
Fl_WidgetCopyLabel btns1(x,y), label
Fl_WidgetSetColorSel(btns1(x,y),Fl_RGB_Color(rnd*255,rnd*255,rnd*255), _
Fl_RGB_Color(rnd*255,rnd*255,rnd*255))
next
Next
Fl_PackEnd pack1
pack2 = Fl_PackNew(0,0,270,200)
btn2= Fl_ButtonExNew(0,0,50,30,"expander2")
Fl_ButtonExSetHandleCB btn2,@ButtonHandleCB
scr2 = Fl_ScrollNew(0,0,50,200)
Fl_WidgetSetType scr2, FL_SCROLL_VERTICAL
For x as integer = 0 to 4
For y as integer = 0 to 44
label = "2"
btns2(x,y) = Fl_ButtonNew(x*50,y*50,45,45)
Fl_WidgetCopyLabel btns2(x,y), label
Fl_WidgetSetColorSel(btns2(x,y),Fl_RGB_Color(rnd*255,rnd*255,rnd*255), _
Fl_RGB_Color(rnd*255,rnd*255,rnd*255))
next
Next
Fl_PackEnd pack2
pack3 = Fl_PackNew(0,0,270,200)
btn3= Fl_ButtonExNew(0,0,50,30,"expander3")
Fl_ButtonExSetHandleCB btn3,@ButtonHandleCB
scr3 = Fl_ScrollNew(0,0,50,200)
Fl_WidgetSetType scr3, FL_SCROLL_VERTICAL
For x as integer = 0 to 4
For y as integer = 0 to 44
label = "3"
btns3(x,y) = Fl_ButtonNew(x*50,y*50,45,45)
Fl_WidgetCopyLabel btns3(x,y), label
Fl_WidgetSetColorSel(btns3(x,y),Fl_RGB_Color(rnd*255,rnd*255,rnd*255), _
Fl_RGB_Color(rnd*255,rnd*255,rnd*255))
next
Next
Fl_PackEnd pack3
pack4 = Fl_PackNew(0,0,270,200)
btn4= Fl_ButtonExNew(0,0,50,30,"expander4")
Fl_ButtonExSetHandleCB btn4,@ButtonHandleCB
scr4 = Fl_ScrollNew(0,0,50,200)
Fl_WidgetSetType scr4, FL_SCROLL_VERTICAL
For x as integer = 0 to 4
For y as integer = 0 to 44
label = "4"
btns4(x,y) = Fl_ButtonNew(x*50,y*50,45,45)
Fl_WidgetCopyLabel btns4(x,y), label
Fl_WidgetSetColorSel(btns4(x,y),Fl_RGB_Color(rnd*255,rnd*255,rnd*255), _
Fl_RGB_Color(rnd*255,rnd*255,rnd*255))
next
Next
Fl_PackEnd pack4
Fl_PackEnd pack0
Fl_WindowShow(win)
Fl_Run
End
function ButtonHandleCB cdecl (self as any ptr,event as Fl_Event) as Integer
dim as string msg = *Fl_WidgetGetLabel(self)
Select case event
Case 1
Fl_WidgetHide(pack0)
Select Case msg
Case "expander1"
If showhide(1)=FALSE Then
showhide(1)=TRUE
Fl_WidgetHide(scr1)
Else
showhide(1)=FALSE
Fl_WidgetShow(scr1)
EndIf
Case "expander2"
If showhide(2)=FALSE Then
showhide(2)=TRUE
Fl_WidgetHide(scr2)
Else
showhide(2)=FALSE
Fl_WidgetShow(scr2)
EndIf
Case "expander3"
If showhide(3)=FALSE Then
showhide(3)=TRUE
Fl_WidgetHide(scr3)
Else
showhide(3)=FALSE
Fl_WidgetShow(scr3)
EndIf
Case "expander4"
If showhide(4)=FALSE Then
showhide(4)=TRUE
Fl_WidgetHide(scr4)
Else
showhide(4)=FALSE
Fl_WidgetShow(scr4)
EndIf
End Select
Fl_WidgetShow(pack0)
End Select
Return 1
end function
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK C for FreeBASIC Jan 09, 2017
Cool I like it !owen wrote:ok, now i'm making progress.
You don't give up before the party started :-)
Only once is very importand you must replace return 1 with return Fl_ButtonExHandleBase(self,event)
All events you don't handle like RESIZE, REDRAW etc. must be delegated to the base class.
Fl_XXXXExHandleBase() is a C call from FreeBASIC inside the C++ FLTK Fl_XXXXEx widget class and it's not optional.
If your application becomes larger and larger or the numbers of used FL_XXXXEx widgets grows
you will run in to problems without the right call of Fl_XXXXExHandleBase()
and this kinds of troubles are hard to find.
Trust me ;-)
The rest looks OK for me good job.
Joshy
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK C for FreeBASIC Jan 09, 2017
Note: You can return 0 also in this case my C++ wrapper calls Fl_XXXHandle() for you.
Again for events you don't handle return 0 or return Fl_XXXXExHandleBase() but never return 1.
Joshy
Again for events you don't handle return 0 or return Fl_XXXXExHandleBase() but never return 1.
Joshy
Re: FLTK C for FreeBASIC Jan 09, 2017
ok thanks joshy.
i will keep that in mind but it seems that return 1 was requried for something but i am not able look into it now.
i am back on the road today for a month or so.
thanks for everything.
i will keep that in mind but it seems that return 1 was requried for something but i am not able look into it now.
i am back on the road today for a month or so.
thanks for everything.
-
- Posts: 139
- Joined: Feb 04, 2011 20:34
- Location: Ontario, Canada
Re: FLTK C for FreeBASIC Jan 09, 2017
The FLTK documentation states:D.J.Peters wrote:Note: You can return 0 also in this case my C++ wrapper calls Fl_XXXHandle() for you.
Again for events you don't handle return 0 or return Fl_XXXXExHandleBase() but never return 1.
Joshy
What else in your wrapper code does not conform to the FLTK documentation?Event Propagation
Widgets receive events via the virtual handle() function. The argument indicates the type of event that can be handled. The widget must indicate if it handled the event by returning 1. FLTK will then remove the event and wait for further events from the host. If the widget's handle function returns 0, FLTK may redistribute the event based on a few rules.
I now have concerns that many months of effort may actually be producing buggy code.
Rod
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK C for FreeBASIC Jan 09, 2017
Hello Rod good morning time to wake up :-) the logic is the same.
The FLTK documentation:
"if it handled the event by returning 1"
FTK-C wrapper:
"if it not handled the event by returning 0 or Fl_XXXExHandleBase()"
1 means hello FLTK please ignore the event I have done all work for you.
0 means hello FLTK please don't ignore the event and do the work for me.
With other words if you return 0 from FreeBASIC to the FLTK C++ wrapper then the wrapper calls return Fl_XXXHandle(widget,event) inside the C++ class.
You as a FreeBASIC "C" coder can't call the C++ Fl_XXXHandle(widget,event) function directly
but you can call Fl_XXXExHandleBase(widget,event) from FreeBASIC.
Of couse you can but if you try it you will see it will crash.
The point are:
step 1: the C++ widget calls your XXXHandleCB() callback
stap 2: if you call from inside the callback return Fl_XXXHandle(widget,event)
the C++ widget will call your XXXHandleCB() again goto step 1: again and again ...
the result are a "out of stackspace"
Let me know if something are unclear.
Joshy
The FLTK documentation:
"if it handled the event by returning 1"
FTK-C wrapper:
"if it not handled the event by returning 0 or Fl_XXXExHandleBase()"
1 means hello FLTK please ignore the event I have done all work for you.
0 means hello FLTK please don't ignore the event and do the work for me.
With other words if you return 0 from FreeBASIC to the FLTK C++ wrapper then the wrapper calls return Fl_XXXHandle(widget,event) inside the C++ class.
You as a FreeBASIC "C" coder can't call the C++ Fl_XXXHandle(widget,event) function directly
but you can call Fl_XXXExHandleBase(widget,event) from FreeBASIC.
Of couse you can but if you try it you will see it will crash.
The point are:
step 1: the C++ widget calls your XXXHandleCB() callback
stap 2: if you call from inside the callback return Fl_XXXHandle(widget,event)
the C++ widget will call your XXXHandleCB() again goto step 1: again and again ...
the result are a "out of stackspace"
Let me know if something are unclear.
Joshy
-
- Posts: 139
- Joined: Feb 04, 2011 20:34
- Location: Ontario, Canada
Re: FLTK C for FreeBASIC Jan 09, 2017
The "pyFLTK" wrapper for Python uses the 0 and 1 return codes exactly as described in the FLTK manual. So why would I need to do anything different when using FreeBasic? So far, my code seems to work using only the 0 and 1 return codes.D.J.Peters wrote:The point are:
step 1: the C++ widget calls your XXXHandleCB() callback
stap 2: if you call from inside the callback return Fl_XXXHandle(widget,event)
the C++ widget will call your XXXHandleCB() again goto step 1: again and again ...
the result are a "out of stackspace"
I wrap selected items from your FLTK wrapper into my own GUI wrapper, so that my application code does not call any of your functions directly. Here's the function that directs all FLTK events to the appropriate GUI object:
Code: Select all
'
'-----------------------------------------------
' Procedure 5 : event router: common events
BeginInternalFunctionCdecl (funCommonEventsRouter) _
BPtr (bvpWidgetRef) _ ' 16882 : fltk widget reference
ParmReturn (typInt32)
'
LocalField (iReturnCode, typInt32) ' 15050 : generic return code
LocalObject (oGenericGadget, objGadget) ' 16082 : generic gui gadget: used as a place holder
LocalField (vFltkEvent, typUInt32) ' 16899 : fltk event number: 0 to 25
'
iReturnCode = iGUI_EVENT_NOT_CAPTURED ' assume the event is not processed
vFltkEvent = funEventNumber () ' get the event number
If NotZero (vFltkEvent) Then
oGenericGadget = Fl_WidgetGetUserData (bvpWidgetRef) ' reference the event object
If IsObject (oGenericGadget) Then
iReturnCode = oGenericGadget->funEvents (vFltkEvent) ' process the event
End If
End If
Return iReturnCode ' return the event result
'
EndInternalFunction
'
Rod
-
- Posts: 8586
- Joined: May 28, 2005 3:28
- Contact:
Re: FLTK C for FreeBASIC Jan 09, 2017
It's the same in FreeBASICBoris the Old wrote:The "pyFLTK" wrapper for Python uses the 0 and 1 return codes exactly as described in the FLTK manual.
inside the Resize and Redraw callbacks for all extened FLTK widgets (Fl_XXXEx) also
If it works for you than it's fine.
pyFLTK has a limitation inside a callback phFLTK can't call C++ Fl_CLASS_NAME::handle(event)
but we FreeBASIC coders can call Fl_CLASS_NAME_EX::HandleBASE() without a crash of recursion.
If you don't need it return 0 or 1 thats all.
But if you create your own missing or new widgets in FreeBASIC (like owen's ExpanderWidget)
Fl_XXXExHandleBase() can and is the only key for tricky things inside callbacks.
Joshy
-
- Posts: 139
- Joined: Feb 04, 2011 20:34
- Location: Ontario, Canada
Re: FLTK C for FreeBASIC Jan 09, 2017
Thanks -- that makes sense.D.J.Peters wrote:But if you create your own missing or new widgets in FreeBASIC (like owen's ExpanderWidget)
Fl_XXXExHandleBase() can and is the only key for tricky things inside callbacks.
My approach to using or expanding widgets is to create classes that use existing widgets. That way, I never have to get involved with the internals of the library that I'm using, and I never risk introducing bugs into my code.
All my applications use custom GUI classes with interfaces that are independent of the GUI library that I'm using. For example, I'm using EZGUI for PowerBASIC code, and now FLTK for FB code. However, the class interfaces are identical, so there is no impact on my application code if I change to a different GUI library.
Rod
Re: FLTK C for FreeBASIC Jan 09, 2017
That is interesting, as i have always wanted a rapidq like gui library, that would use fltk under the hood. I didn't start it because it would be a LOT of work. If you method is simple then great.
Re: FLTK C for FreeBASIC Jan 09, 2017
I have a question about the naming conventions used:
Why does the first set have no underscore between Choice and SetValue and between Choice and GetValue, but the second has an underscore between Input and SetWrap and between Menu and GetMenu? I only ask because it seems like no matter which I guessed when working with a widget for the first time, I guessed wrong.
Code: Select all
Fl_ChoiceSetValue(test,0)
Fl_ChoiceGetValue(test2)
Fl_Menu_GetMenu(test3)
Fl_Input_SetWrap(test4, TRUE)