FLTK-C-1.3.3 for FreeBASIC

[owen]

no, not hide the button when clicking the button
rather
hide the box when clicking the button

[owen]

oh, you edited your post and I see you use:
Fl_WidgetSetUserData(btn,box)
it works but not sure how

[D.J.Peters]

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

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()

[owen]

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.

[owen]

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)

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

[D.J.Peters]

ok, now i'm making progress.

Cool I like it !

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

[D.J.Peters]

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

[owen]

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.

[Boris the Old]

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

The FLTK documentation states:

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.

What else in your wrapper code does not conform to the FLTK documentation?

I now have concerns that many months of effort may actually be producing buggy code.

Rod

[D.J.Peters]

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

[Boris the Old]

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"

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.

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
'

By the way, this is machine generated code that makes heavy use of macros and Hungarian notation.

Rod

[D.J.Peters]

The "pyFLTK" wrapper for Python uses the 0 and 1 return codes exactly as described in the FLTK manual.

It's the same in FreeBASIC
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

[Boris the Old]

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.

Thanks -- that makes sense.

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

[JohnK]

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.

[Imortis]

I have a question about the naming conventions used:

Code: Select all

Fl_ChoiceSetValue(test,0)
Fl_ChoiceGetValue(test2)

Fl_Menu_GetMenu(test3)
Fl_Input_SetWrap(test4, TRUE)

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.