FLTK-C-1.3.3 for FreeBASIC

[Linuxbob]

I need a little advice.

I am working on a small program to learn how to use FLTK. Part of a callback function retrieves the information in Fl_Input controls. The return type for the function Fl_Input_GetValue() is a Zstring pointer. The Fl_Input controls are initialized properly so the pointers to the controls are valid. So, here is a snip of the code:

Code: Select all

dim as zstring ptr zx,zy
...
zx = Fl_Input_GetValue(inXInput)
zy = Fl_Input_GetValue(inYInput)


Compilation fails on these functions with the message:

error 181: Invalid assignment/conversion in 'zx = Fl_Input_GetValue(inXInput)'
error 181: Invalid assignment/conversion in 'zy = Fl_Input_GetValue(inYInput)'

What am I missing?

[D.J.Peters]

The return type for the function Fl_Input_GetValue() is a Zstring pointer.

No it's const zstring ptr
declare function Fl_Input_GetValue(byval ip_ as Fl_Input_ ptr) as const zstring ptr

this will return a const zstring pointer: var pValue = Fl_Input_GetValue(widget)
this will return a string (a copy): var sValue = *Fl_Input_GetValue(widget)

Joshy

[Linuxbob]

No it's const zstring ptr

Joshy

That's what I was missing, thanks.

[Baptiste]

Hello ,

I again thank D.J Peters for this beautiful tool that is FLTK.

is it possible with "FLTK" to create a listview with sorting by clicking on columns and selections of the elements of a line and color highlights.
I looked in the examples delivered with the application but I did not find

Thank you .

[D.J.Peters]

is it possible with "FLTK" to create a listview with sorting by clicking on columns and selections of the elements of a line and color highlights.

You can use a Fl_Multi_Browser() as all other browsers it supports sorting order's row selection colums labels and so on ...
or you can use a Fl_Table or you build your own Fl_ListView (extends a Fl_GroupEx but this is more for advanced GUI coders).

Joshy

Code: Select all

#include once "fltk-c.bi"

' test of: Fl_Multi_BrowserNew()

sub BrowserCB cdecl(byval self as FL_WIDGET ptr,byval userdata as any ptr)
  var brw = cptr(Fl_Browser ptr,self)
  print "BrowserCB !"
end sub

'
' main
'
Fl_SetScheme("gleam")

var win = Fl_Double_WindowNew (800,400,"FL_MULTIBROWSER !")
var brw = Fl_Multi_BrowserNew(10,10,Fl_WidgetGetW(win)-20,Fl_WidgetGetH(win)-20)
Fl_Browser_SetHasScrollbar(brw,FL_SCROLL_BOTH)
Fl_WidgetSetCallbackArg(brw,@BrowserCB,0)
Fl_WidgetSetSelectionColor(brw,FL_RED)

dim as long widths(...)=>{80,100,120,70,0}
var nCols = ubound(widths)
var nRows = 50
Fl_BrowserSetColumnChar(brw,asc(","))
Fl_BrowserSetColumnWidths(brw,@widths(0))
Fl_BrowserAdd(brw,"Label 1,Label 2,Label 3,Label 4")
for r as integer = 1 to nRows
  var sRow = "r:" & r
  var sCols = ""
  for c as integer = 1 to nCols
    sCols &= sRow & " c:" & c & iif(c<nCols,",","")
  next 
  Fl_BrowserAdd(brw,strptr(sCols))
next 

Fl_GroupSetResizable(win,brw)
Fl_WindowShow(win)
Fl_Run()


[Baptiste]

thank you D.J. Peters,

I'll look at it

[Linuxbob]

Follow up question on setting a box value.

Code: Select all

    dim shared as Fl_Box ptr bxanswer
    dim as string sz
    dim as const zstring ptr zs
    ...
    bxAnswer = Fl_BoxNew(360,240,170,30,"  ")
    ...
    '-- display the results
    Fl_WidgetRedraw(bxxPlotAnswer)
    sx = str(Datapoint.xval): sy = str(Datapoint.yval)
    if SolveR then
        sz = sx + "<" + sy
    else
        sz = sx + "," + sy
    end if
    print sz
    zs = strptr(sz)
    print zs, *zs
    Fl_WidgetSetLabel(bxAnswer, zs)

The print statements are just for diagnostic purpose. When the programs, everything runs properly, except the last Fl_WidgetSetLabel call does not display the zstring zs properly. The two print statements show me the string and zstring are formatted correctly. But, the text that shows in bxAnswer starts with gibberish characters, then ends with the last five or six characters being correct.

Example run: The correct answer as shown in the console is -44.95,111.26. Both sz and *zs indicate this answer. What is displayed in bxAnswer is:

&$^#&*$^^$%*#$11.26

Thoughts?

[badidea]

&$^#&*$^^$%*#$11.26
Thoughts?

The data to which zs points is not valid any more?

FLTK does not make a copy of the data. So as as "bxAnswer" exists, the text for the label pointed to by zs must be there.
If you try Fl_WidgetSetLabel(bxAnswer, "static text"), you will probably see that this works fine. This static text exists at the same location untill program termination.

Do you have complete code to test with?
Try with: dim shared as string sz Probably not safe.

Note : I could be wrong. I don't use FLTK (or any toolkit/GUI) a lot.

[Linuxbob]

The data to which zs points is not valid any more?

Do you have complete code to test with?
Try with: dim shared as string sz

The data is still valid...the statement "print zs,*zs" just before WidgetSetLabel gives me both the pointer's address contents and the correct string data.

The program is complete and thoroughly tested. I get the correct results every time (verified manually.) This is just the last piece that doesn't function as intended.

I don't need sz to be shared. Both sz and zs are only local variables declared in the sub and only appear in the snippet I've posted. The widget is declared shared at the module level. I am using sz as a normal string so I can use the native FB string handling functionality to assemble the answer. The wiki says that using strptr() is the only real correct way to get a zstring pointer from a FB string. Also, the wiki indicates that a pointer declared as a "const <type> pointer" can change its contents during runtime; only the underlying data can't be changed. Which is true, I don't get a runtime error when the statement "zs = strptr(sz)" executes.

The strangeness is that a few characters at the end of the zstring display correctly. That tells me the zstring has a proper '\0' terminator. If the front end of the zstring has garbage, then the FB "print" statement is self-correcting, which I don't believe is true.

[badidea]

... Both sz and zs are only local variables declared in the sub and only appear in the snippet I've posted...

I still think that that is exactly the problem, but I have to write code first to test it.
Else, UTF-8 trouble...

[D.J.Peters]

If you use Fl_WidgetSetLabel the string must exist thru the whole lifetime of the widget.
Fl_WidgetSetLabel( aWidget, "a label")

If you use Fl_WidgetCopyLabel the widget self allocates the space for the string.
var aLabel = "a label" : Fl_WidgetCopyLabel( aWidget, strptr(aLabel) )

[Linuxbob]

Fl_WidgetCopyLabel worked, thanks!

[Coolman]

excellent work. but the advantage of fltk is the static compilation, which allows you to distribute programs without too many dependencies. under linux, i compiled the latest version of fltk. the default choice is to produce static libraries. why did you choose shared libraries? it complicates the distribution of the generated programs.

[D.J.Peters]

FreeBASIC can't link to (complex) C++ libraries (static nor shared)
so you need a dynamic linkable C wrapper I hope that makes sense for you.

What you get in one small 1.5MB library on Linux and Windows (32 and 64-bit):

A complete 2D Vector Graphic engine.
Full UTF8 support for all widgets and text and files system (normally windows file system isn't UTF8)
Full OpenGL support, Vector Font's, Clippboard, simple to use "but complete" printer interface, a bunch of image format's, and so on ...

And the best are FLTK is a kind of toolbox for GUI coding.

That means if you like the functionality of any FLTK widget
(the mouse control, keyboard input, copy of content ... all these stuff done by FLTK)
but not it's look you can simple write your own widget.draw method without to reprogramm a complete new widget.
On other site if you miss a widget it's easy to code your own new widget in FreeBASIC.

At the beginning of FreeBASIC around 2005 I used GTK with the C API
but creating a window and a simple button needs 40MB of GTK libraries on windows this wasn't acceptable for me.

bla bla bla :-)

Joshy

[Coolman]

All right, I understand. I asked the question because in the beginning you provided static libraries.

As far as Gtk is concerned, I agree...