Slippy GUI

[BunnX]

Hey :)

I created a little Gui system for freebasic. The major thing is, that it's object orientated.

Here's a screenshot:
http://bunnxchat.de/gui.jpg

Download:
http://bunnxchat.de/slippy.zip
(ver 0.1a)

Features:

• Buttons (woho)
• Cursor editable textboxes
• Progressbars
• Soundobject (only for windows)
• Checkboxes
• Labels
• Picturebox
• Listboxes

Planned:

• Slider
• Multiline textbox ( maybe, but if this gui get great, than for sure )
• File listbox
• Folder listbox
• Combobox for drives
• Radiobuttons
• Combobox
• Optimization:
• Optimize Text drawing with cursor
• Buffering allready drawn graphics

Greets BunnX.

Edit: Testet successfully under linux. If you use linux, remove the sound object code from demo.bas.

[BunnX]

Here is my font converter. So you can develop varios fonts (the included font isn't complete yet). You need a 24bit bitmap named "font.bmp" and sized to 192*192 pixels. So you have 12*12 pixels per char. Gimp bmp's didn't work for me, the header lenght have to be 54. In this case, open the bmp with paint, make a dot, save, redo, save... mspaint bmp's are working. After this, the converter takes the redchanel, 0 is a pixel, 255 is background and compress the data.

Here's the original font: http://bunnxchat.de/font.bmp

After compression, you can convert the resulting "pixmap" file with bin2bas to a basic byte array and replace compress_font() in the slippy_gui.bi or include it.

Converter:

Code: Select all

Type rgbT
	r 	As UByte
	g 	As UByte
	b	As UByte
End Type

Type StringT
	stAdd 	As Any Ptr
	stLen	As UInteger	
	stMem	As UInteger
End Type

Dim pixel(36864) 				As UByte
Dim compresspixel(36864) 	As UByte

Declare Function LZW_Encode Alias "fb_hEncode" ( ByVal in_buffer  As Any Ptr, ByVal in_size As Integer,  ByVal out_buffer As Any Ptr, ByRef out_size   As Integer) As Integer

ScreenRes 300, 300, 32

If Open("font.bmp" For Binary Access Read As #1) <> 0 Then Print "Could not open font.bmp":Sleep:End
Dim As String reader = Space(Lof(1) - 54)
Get #1, 55, reader
Close #1

If Len(reader) <> 36864 * 3 Then Print "font.bmp size not as expected... 192 * 192 pixel 24bit bitmap. (12 pixel font size...)":Sleep:End

Dim As Integer pixelX, pixelY, drawX, drawY, x, y
Dim As rgbT Ptr rgbPtr = *(Cast(UInteger Ptr, @reader))
Dim As UInteger c

drawX = 0
drawY = 200

For y =  191 To 0 Step - 12
	For x = 0 To 191 Step 12
		For pixelY = y To y - 11 Step - 1
			For pixelX = x To x + 11
				If (rgbPtr + pixelX + pixelY * 192)->r = 0 Then
					pixel(c) = 0
				Else
					pixel(c) = 1
				EndIf
				c += 1
			Next
		Next
		drawX += 2
	Next
	drawX = 0
	drawY -= 2
Next

Dim As Integer csize = 36864
LZW_Encode(@pixel(0), 36864, @compresspixel(0), csize)

Dim As String Ptr writerPtr
Dim As StringT writer
writerPtr = @writer
writer.stAdd = @compresspixel(0)
writer.stLen = csize
writer.stMem = csize

Kill "pixmap"
Open "pixmap" For Binary Access write As #1
Put #1, 1, *writerPtr
Close #1

Print "Done."
sleep

[fxm]

The last point is a important thing, at this time, the program chrashes somethimes if you want to stop it. I don't know much about this threading stuff. It would be nice if you take a look.

Hello BunnX, welcome to the forum!

Proposed corrections, to improve the terminaison of the thread (you can ask for explanation):

- In slippy_gui.bi, Sub Slippys_Intern_Stuff():
Suppress the last line 'gui->quit()'

- In slippy_gui.bi, replace Sub slippy_gui.quit() by only:

Code: Select all

Sub slippy_gui.quit()
  This.running = 0
End Sub

- In slippy_gui.bi, Type slippy_gui, add the following function:

Code: Select all

Function slippy_gui.ended() As Integer
  If This.running <> 0 then Return 0
  ThreadWait(This.thread)
  DeAllocate(This.clearBuffer)
  MutexDestroy(This.mutex)
  Return 1
End Function

- In slippy_gui.bi, Function s_sound.load():
Modify the line as following 'If Open (file For Binary Access Read As #reader) <> 0 Then Return 0'

- In demo.bas, replace the instruction 'Loop' with 'Loop Until gui.ended()'.

General remark:
You could also suppress all warnings!

[BunnX]

Thank you! :) I did the changes and it's running now how expected. The download link in the entry post, i've updated too.

Explanations are always good :D This evening, I visited a friend and he is hobby programmer, too. He told me, thats not a good idea to clear objects cause they do this at them self and want to call the deconstructor. So I can image what was wong with this clearing sub. And the threading thing... It's right that the tread can't call a sub thats want to stop it? Cause originally I wrote a threadwait() into .quit() and it was waiting forever. I did not got to your idea, now I think it's plausible to me, cause the thread expected the return. Thank you. But threads are still baffling in some kind.

Cause this is done, I have many motivation (programms that exit with a crash aren't a good motivation ;) ) and will update soon for more functionality.

BunnX

[fxm]

I see your friend has well explained the thread use.

But among all warnings, you must correct at least this:
warning 3(1): Passing different pointer types, at parameter 1 of THREADCREATE()

You must always pass an untyped pointer (Any Ptr) to a thread, otherwise this may induce crash.
So you must redefine the pointer type inside the thread body.
2 lines to change + 1 line to add:

Code: Select all

Declare Sub Slippys_Intern_Stuff( ByVal any_ptr_gui As Any Ptr )
'.....
Sub Slippys_Intern_Stuff( ByVal any_ptr_gui As Any Ptr )
	Dim As slippy_gui Ptr gui = any_ptr_gui
'.....

Remark: I have not look at the part concerning the sound, but you must at least add a destructor to free the allocated memory.

Code: Select all

Destructor s_sound( )

	With This
    If .memory <> 0 Then
      Deallocate(.memory)
    End If
	End With

End destructor

[BunnX]

I've done the changes, thanks :) But the second warning.. it's a little "hack" from me to load data with a definied size to a pointer without having a type that match this size. So I recreate the inernal FB string sctructur. Maybe there's another easy way to load comfortable?

Now I added the picturebox control and restructured the code. The objects can now draw themself, so the thread haven't this long calls anymore and to make use auf "Private:" marks, to prevent thats the programmer can pass something that will cause a crash (the new version is fully incompatile to the last). I also added a version number to prevent confusion, it's now 0.1 :)
And I added new goals.

Edit: Of course the picturebox will get methods for set and read pixels later.

[fxm]

But the second warning.. it's a little "hack" from me to load data with a definied size to a pointer without having a type that match this size. So I recreate the inernal FB string sctructur. Maybe there's another easy way to load comfortable?

Code: Select all

Type s_sound
  Declare Function load( ByVal file As String ) As Integer
  Declare Function play() As Integer
  Declare Destructor()
  Private:
  loaded As UByte
  'memory As Any Ptr
  memory As UByte Ptr
End Type

Code: Select all

Function s_sound.load( ByVal file As String ) As Integer
	
  Dim reader As Integer = FreeFile
  'Dim As string_help stringh
  'Dim As String Ptr stringhPtr
  'stringhPtr = @stringh
  With This
    If Open (file For Binary Access Read As #reader) <> 0 Then Return 0
    If .memory <> 0 Then
      'ReAllocate(.memory, Lof(reader) + 1)
      ReAllocate(.memory, Lof(reader))
    Else
      '.memory = Callocate(Lof(reader) + 1)
      .memory = Allocate(Lof(reader))
    End If
    'stringh.stPtr = .memory
    'stringh.stLen = Lof(reader)
    'stringh.stMem = stringh.stLen
    'Get #reader, 1, *stringhPtr
    Get #reader, 1, *.memory, Lof(reader)
    Close #reader
    .loaded = 1 
	End With
  'Clear(stringh, 0, SizeOf(string_help))
	Return 1
	
End Function

[BunnX]

Ok, never noticed that Get has a len parameter. So much for "easy" :D Learned something for the future.

[BunnX]

Little update here :)

Changelog:

v0.1a
=====
- No compiler warnings.
- Events concepted as flags.
- Added event: EVT_MOUSE_MOVE.
- Eventhandler got 2 integer parameter (mostly used for x, y).
- Picturebox control got 2 new methods.

• setPixel32(x, y, color) as integer
• getPixel32(x, y) as ulong

- Picturebox has a transparent color, used if s_picturebox.transColor <> 0.
- Completed 256 Byte Ascii font, added creation tool to source package.
- Added Listbox control.
- Changed textbox input routines.

The Textbox schould be better to use and don't have this pseudocursor anymore, but I have problems to get the cursorposition in relation. If anybody have an idea, I am open for anything new.

BunnX

Edit: I got a fix question, I changed all color variables to long to prepare for 64 bit version. Will a long be a 32 bit number for the 64 bit compiler? Integer aren't as i know :)

[Merick]

With whatever version of the compiler, you can't go wrong with using an "unsigned integer" to hold colors for 32bit mode graphics, since that's what's returned by the RGB and RGBA color macros.

[BunnX]

Yes, thank you :) But I meant for pointers, too. For read/write in memorybuffers. I found this: http://www.freebasic-portal.de/befehlsr ... n-383.html Long will stay at 4 Byte.

[Merick]

When working with pointers, you need to remember that the size of a pointer is not the same size as the data type you are making a pointer too.

I could be wrong, but I believe this is the way it works:

A pointer needs enough room to hold the memory address where you are storing the data. On a 32bit system memory addresses use 4 bytes, so a pointer will always be 4 bytes, and on a 64bit system memory addresses use 8 bytes, so all pointers will be 8 bytes - even if the data type you made the pointer for only holds 1 byte.

Unless you are trying to copy the memory address from a pointer to a regular variable, you shouldn't need to worry about it.

[BunnX]

The storage size for the pointer itself is not the problem. But the size of the type the pointer is declared, the pointer will return the amount of data in the size of it's type. Also when incrementing a pointer with 1, is the new address the actual + sizeof(type). This means, if in 64 bit version a integer is 64 bit long, a integer pointer will reference 2 pixels. If you increment it with 1, the next 2 after the actual 2 pixel. So my routines will exceed my allocated memory twice. Cause I use for example:

color = *(integerptr + xpos + ypos * graphicwidth)

If xpos and ypos = 1 and width = 100, then it reads with an 8byte integer ptr 808 bytes after starting address, with a 32 bit type pointer (4 byte integer or long), it would be 404 bytes.

By the way, this can speed up drawing/reading for graphic with width/height is an power of two :) Only the useless bits must be shiftet out when readed to get one color, but memory operations would be the half. I'm curios about 64 bit fb :3