GUI library for Windows \ Linux (window9)

[VANYA]

Library update:

Windows , Linux
Add:
UTF8ToUnicode
UnicodeToUTF8
GetSystemDefaultFont
GetCurentDefaultFont
GetNameFromFont
GetSizeFromFont
GetStyleFromFont
GetSizeStringFromFont
SetFocus
GetFocus
SetWindowProperty
GetWindowProperty
DeleteWindowProperty

Renamed functions SizeX , SizeY in the w9SizeWidth , w9SizeHeight
Minor fixes and improvements.

Only Windows
Added optional parameter for ShellFolder

[VANYA]

Updated English help:
RNBW did a great job of cleaning up the help from unnecessary garbage, edited the styles, made changes to some articles that I translated incorrectly. Many thanks!

[operator+]

Hi. Could you make this library usable from plain C?

I mean plain C. I used to see C++ headers on this very thread which isn't what I'm seeking.

Thanks.

Update: let me make it more clear. I'm asking about a plain C compatible DLL and a plain C header. I wanted to make a binding to C# (use P/Invoke, so need a plain C compatible DLL and [optionally] a plain C header as the preference) and Pascal (link with the DLL itself, the Pascal header will be created with the help of h2pas tool which expect a plain C header as the input). Maybe Java, too, using JNA. JNA expects a plain C compatible DLL to be able to load and use it.

[VANYA]

Hi. Could you make this library usable from plain C?

Porting a library to other languages ​​is a time-consuming and unjustified process. I'm not interested.

[operator+]

Hi. Could you make this library usable from plain C?

Porting a library to other languages ​​is a time-consuming and unjustified process. I'm not interested.

No. The library is still written in FB. One could use a library written in C++ in plain C as well after creating a flatterned interface for this library. The process is basically flattern OOP concepts into plain procedural code, making a plain C interface DLL and a plain C header.

Because I don't know FB, so I asked you first. In window9.bi it's already pretty much procedural, only OOP part is namespace window9 and a class (type) which I don't know what they really do at all. Creating an interfacing library for C would be easy if not effortless, given one must known FB.

Demo:

Also in FB written the interfacing plain C library.

Use opaqe type instead of re-implement part of FB runtime (FBString) in C like your C++ demo. Indeed it's pulling the FB runtime in.

cinterface.bas

@include once "extWString.bi"

type MyString
end type

declare function MyString_New as MyString
return Cast(MyString, UString) // don;t know the syntax since I don't know FB

Another approach is proving a way to convert back and forth between C const char* and FBString/UString (maybe have performance impact compared to the first approach). But overral everything is still written in FB including the interfacing C library.

https://github.com/MicrosoftDocs/cpp-do ... ern-cpp.md

Update: to be more clear, nothing change to the current library. I asked you to provide additionally a plain C interface DLL and header to be callable from other language. The interface library is also written in FB.

[VANYA]

operator+!

I'm not interested!!!!!!

[Mysoft]

Hi. Could you make this library usable from plain C?

I mean plain C. I used to see C++ headers on this very thread which isn't what I'm seeking.

Thanks.

Update: let me make it more clear. I'm asking about a plain C compatible DLL and a plain C header. I wanted to make a binding to C# (use P/Invoke, so need a plain C compatible DLL and [optionally] a plain C header as the preference) and Pascal (link with the DLL itself, the Pascal header will be created with the help of h2pas tool which expect a plain C header as the input). Maybe Java, too, using JNA. JNA expects a plain C compatible DLL to be able to load and use it.

wanna join my discord server? https://discord.com/channels/8542280244 ... 2584425472 i can help you with that so you can have a w9-c, as i think this library have potential, so having it usable on other languages is helpful for the project, if done seamlessy... then i can support the w9-c, to not overpressure vanya

[Mysoft]

Now checked all your problems on 20.04

Catch_Image , StatusBarGadget , ResizeWindow - work fine

ok so lets start with those... i installed a ubuntu 20.04 VM, and got the same results and my friend with window9 (re-downloaded today), and etc...
and same issues there... so lets start one thing at time Catch_Image

i'm using gtk2 version of the library with freebasic 1.08.1 for 64bit and this is my code (the image is on code, to make it not require a image file, but the exact same thing happen with the raw sample from documentation)

Code: Select all

#Include "window9.bi"

Dim As Integer event
Dim As HWND hwnd

type InMemoryBitmap field=1
  'BITMAPFILEHEADER
  bfType        as short   'cvshort("BM")
  bfSize        as ulong   'biSizeImage+bfOffBits
  Reserved      as ulong   '0
  bfOffBits     as ulong   'sizeof(InMemoryBitmap)
  'BITMAPINFO
  'BITMAPINFOHEADER
  biSize        as ulong   'sizeof(bitmapinfoheader)
  biWidth       as ulong   'width
  biHeight      as ulong   '-height
  biPlanes      as ushort  '1
  biBitCount    as ushort  '32?
  biCompression as ulong   '0 (BI_RGB)
  biSizeImage   as ulong   '(biWidth*abs(biHeight)*biBitCount\8)
  biXPels       as ulong   '0
  biYPels       as ulong   '0
  biClrUsed     as ulong   '0
  biClrPriority as ulong   '0
end type

type ImageStruct field=1
  tHdr as InMemoryBitmap
  Pixels(16*16*4) as ulong
end type

const A=BGR(0,0,0) , B=BGR(64,64,64) , C = BGR(255,128,64) , D = BGR(64,128,255)

dim as ImageStruct tImage = ( _
  (cvshort("BM"),-1,0,54,40,16,-16,1,32) , _    
  {a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,b,a,b,a,b,a,b,a,b,a,b,a,b,a, _
   a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,C,C,C,C,C,C,C,C,C,C,C,C,b,a, _
   a,b,C,b,a,b,a,b,a,b,a,b,a,C,a,b, _
   b,a,C,a,b,a,b,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,D,D,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,D,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,D,b,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,D,a,b,a,D,a,b,C,b,a, _
   a,b,C,b,a,b,D,D,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,b,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,a,b,a,b,a,b,a,C,a,b, _
   b,a,C,C,C,C,C,C,C,C,C,C,C,C,b,a, _
   a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,b,a,b,a,b,a,b,a,b,a,b,a,b,a _   
  } )
rem ------------------------------------------------
with tImage.tHdr 'maybe unecessary, but for completeness
  .biSizeImage = (.biWidth*abs(.biHeight)*.biBitCount\8)
  .bfSize = .biSizeImage+.bfOffBits
end with

dim as any ptr hgMem = @tImage

print ">>> OpenWindow() <<<"
hwnd=OpenWindow("",10,10,128,128) : CenterWindow(hwnd)
print ">>> Catch_ImageA() <<<"
' !!! Happens just the same with the raw incbin sample !!!
var hImg = Catch_ImageA(hgmem)
print ">>> Resize_ImageA() <<<"
Resize_ImageA( hImg , 64 , 64 )
print ">>> createHBitmapFromGpBitmap() <<<"
var hImg2 = createHBitmapFromGpBitmap( hImg )
print ">>> ImageGadget() <<<"
ImageGadget(1,25,16,64,64,hImg2)

Do
 event=WaitEvent()
 If Event=EventClose Then End
Loop

and so i get those GTK stuff before the obvious crash...
>>> OpenWindow() <<<
>>> Catch_ImageA() <<<
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_has_alpha: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_calculate_rowstride: assertion 'width > 0' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_fill: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_pixels_with_length: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_rowstride: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GdkPixbuf-CRITICAL **: 15:16:29.734: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
(imgtst:76428): GLib-ERROR **: 15:16:29.734: ../../../glib/gmem.c:337: overflow allocating 18446744073709551615*18446744073709551615 bytes
./c, linha 1: 76428 Trace/breakpoint trap (imagem do núcleo gravada) ./$1

so this tells me two things... 1 theres a faillure happening very soon on the process, but the function is not "failing fast" it goes all the way till the point it tries to allocate -1 * -1 as unsigned bytes

and that it isnt working on linux for me, (what else you wish me to do to help?) next slice of time i will try to compile window9 on linux and see if i can find on its source where it fails and why...

[Mysoft]

also as for the documentation....

for GetSizeFromFont()

Gets the font size. in windows there is no way to get the size for the system font that is obtained by using GetSystemDefaultFont

doesnt GetObject() returning a LOGFONT does the trick for this one?

[SARG]

@Mysoft

I tested with includebinary an external bmp file without any problem.

There are at least 2 problems in your BMP format :
- ulong for height as -16 gives a very big number so the size is huge. Using long is better.

The second point shiould not be a real problem.
- in pixels(16*16*4) *4 is not necessary as ulong implies 4 bytes. And zero based so 16*16-1 should suffice



But even with those changes always a crash. Maybe something is still wrong in the format.
Or the pointer for includebinary is more than just a pointer to the array..... Let VANYA answser.

[Mysoft]

@Mysoft

I tested with includebinary an external bmp file without any problem.

There are at least 2 problems in your BMP format :
- ulong for height as -16 gives a very big number so the size is huge. Using long is better.

The second point shiould not be a real problem.
- in pixels(16*16*4) *4 is not necessary as ulong implies 4 bytes. And zero based so 16*16-1 should suffice

But even with those changes always a crash. Maybe something is still wrong in the format.
Or the pointer for includebinary is more than just a pointer to the array..... Let VANYA answser.

hum... even that it would be ulong it would still be 32bit, so it should be fine, but indeed i changed it to long as its correct for those...
well that could be it... because i believe on my tests i did load the bmp with from file, with same results, but so if it differs on windows linux, it should be documented i guess

also one detail, the status bar indeed works, what fails is GetGadgetY / GetGadgetHeight for the status bar, those always return 0 on linux, so the "paint of the background was being calculated wrong, and overriding the status bar, (unlike the menu that appeared on top of it)), but another detail that differs on windows/linux and isnt documented hehe

[VANYA]

@Mysoft

Catch_image is related to IncludeBinary . You are using a hacky way to deliver an image. I will not even analyze the correctness of the transferred image, but how in your example will Catch_image get the size of the buffer? Before using any hacker tricks, you need to study everything well! Here is a quote from the help:

RUSSIAN:

Позволяет из массива с байтами , получить битмап. Функция используется в связке с IncludeBinary. Функция IncludeBinary бинарно вкладывает изображение в текущий модуль, а функция CatchImage извлекает из него и преобразует в битмап.

ENGLISH:

Allows you to get a bitmap from an array with bytes. The function is used in conjunction with IncludeBinary. The IncludeBinary function binary embeds the image in the current module, and the CatchImage function extracts from it and converts it to a bitmap

Do you see somewhere that Catch_image is a self - sufficient function?

And on this basis, you have already said many posts in the topic that functions commit CRASH and mislead me and others! That is why I did not give users a manual mechanism for specifying the buffer size. After all, you will make mistakes (for example, slip the into Catch_image function an image with errors), and then you will prove to me here that the functions are bad, crash out of the blue, etc.

To make it clear to you that you are wrong, I will show you an example that your image can be loaded if everything is done correctly, even in a hacky way (Linux):

Code: Select all

#Include "window9.bi"

Dim As Integer event
Dim As HWND hwnd

type InMemoryBitmap field=1
  'BITMAPFILEHEADER
  bfType        as short   'cvshort("BM")
  bfSize        as ulong   'biSizeImage+bfOffBits
  Reserved      as ulong   '0
  bfOffBits     as ulong   'sizeof(InMemoryBitmap)
  'BITMAPINFO
  'BITMAPINFOHEADER
  biSize        as ulong   'sizeof(bitmapinfoheader)
  biWidth       as ulong   'width
  biHeight      as ulong   '-height
  biPlanes      as ushort  '1
  biBitCount    as ushort  '32?
  biCompression as ulong   '0 (BI_RGB)
  biSizeImage   as ulong   '(biWidth*abs(biHeight)*biBitCount\8)
  biXPels       as ulong   '0
  biYPels       as ulong   '0
  biClrUsed     as ulong   '0
  biClrPriority as ulong   '0
end type

type ImageStruct field=1
  tHdr as InMemoryBitmap
  Pixels(16*16*4) as ulong
end type

const A=BGR(0,0,0) , B=BGR(64,64,64) , C = BGR(255,128,64) , D = BGR(64,128,255)

dim as ImageStruct tImage = ( _
  (cvshort("BM"),-1,0,54,40,16,-16,1,32) , _    
  {a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,b,a,b,a,b,a,b,a,b,a,b,a,b,a, _
   a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,C,C,C,C,C,C,C,C,C,C,C,C,b,a, _
   a,b,C,b,a,b,a,b,a,b,a,b,a,C,a,b, _
   b,a,C,a,b,a,b,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,D,D,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,D,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,D,b,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,D,a,b,a,D,a,b,C,b,a, _
   a,b,C,b,a,b,D,D,D,D,D,b,a,C,a,b, _
   b,a,C,a,b,a,b,a,b,a,b,a,b,C,b,a, _
   a,b,C,b,a,b,a,b,a,b,a,b,a,C,a,b, _
   b,a,C,C,C,C,C,C,C,C,C,C,C,C,b,a, _
   a,b,a,b,a,b,a,b,a,b,a,b,a,b,a,b, _
   b,a,b,a,b,a,b,a,b,a,b,a,b,a,b,a _   
  } )
rem ------------------------------------------------
with tImage.tHdr 'maybe unecessary, but for completeness
  .biSizeImage = (.biWidth*abs(.biHeight)*.biBitCount\8)
  .bfSize = .biSizeImage+.bfOffBits
end with

dim as any ptr hgMem = @tImage

print ">>> OpenWindow() <<<"
hwnd=OpenWindow("",10,10,128,128) : CenterWindow(hwnd)
print ">>> Catch_ImageA() <<<"
' !!! Happens just the same with the raw incbin sample !!!
pGlobalTypeWindow9->ListIncBin->addNodeSub(Cint(hgMem) , sizeof(ImageStruct))
var hImg = Catch_ImageA(hgmem)
print ">>> Resize_ImageA() <<<"
Resize_ImageA( hImg , 64 , 64 )
print ">>> createHBitmapFromGpBitmap() <<<"
var hImg2 = createHBitmapFromGpBitmap( hImg )
print ">>> ImageGadget() <<<"
ImageGadget(1,25,16,64,64,hImg2)

Do
 event=WaitEvent()
 If Event=EventClose Then End
Loop

In windows, this is also possible, but I'm too lazy to reboot the system and generally engage in these entertainments.

--------------------------

also one detail, the status bar indeed works, what fails is GetGadgetY / GetGadgetHeight for the status bar, those always return 0 on linux, so the "paint of the background was being calculated wrong, and overriding the status bar, (unlike the menu that appeared on top of it)), but another detail that differs on windows/linux and isnt documented hehe

The size of the StatusBarGadget cannot be obtained and cannot be changed manually (there is no such functionality in the library), at least on linux. But I can already tell the size of the StatusBarGadget on linux (it is standard):

width_main_window X 25

added last:
I will make it possible to change the height size for the StatusBarGadget and also get the width and height size on linux

[SARG]

@Mysoft
Ulong and long are same values in memory but when use as variable or structure field in calculations there is a big difference.

Code: Select all

dim as long lg=-16
dim as ulong ulg=-16

print lg,abs(lg)
print ulg,abs(ulg)
sleep

Just to avoid futures bugs

@VANYA
Yes for my last sentence I was thinking also about UboundIncBin

[Mysoft]

@Mysoft
Ulong and long are same values in memory but when use as variable or structure field in calculations there is a big difference.

Code: Select all

dim as long lg=-16
dim as ulong ulg=-16

print lg,abs(lg)
print ulg,abs(ulg)
sleep

Just to avoid futures bugs

@VANYA
Yes for my last sentence I was thinking also about UboundIncBin

well... sure, i know, but on my sample code, i just set ulong to a value, no math at all, hence why i said it does not matter, since the other side would use it as long anyway hehe, so i was just saying that even that i forget to set those as long, they are no problem for the sample code

[Mysoft]

@Mysoft

Catch_image is related to IncludeBinary . You are using a hacky way to deliver an image. I will not even analyze the correctness of the transferred image, but how in your example will Catch_image get the size of the buffer? Before using any hacker tricks, you need to study everything well! Here is a quote from the help:

well... it should not need the size of the buffer to load images (as long they are complete images that is), except as to validate buffers (if any encoder need such sizes) but yes... either way... this is kinda flawed because you had a functionality that is more useful to actually grab images from memory or cache compressed images on memory, or download them, or retrieve from other forms, and no way to load them, so i would say to keep the size as an optional parameter, for when its not used by IncludeBinary

and yes i'm using in a hacky way, because thats the only way to have an image buffer from pointer, since there isnt a function to get/set bitmap bits, or to access them directly... and since it does not crash at all on windows, and it would require me to check the source to know the truth of that, i just used common sense... however it still does not explain why even the default sample crashed on linux, but i think it was crashing on incbin part, that i had to put incbin inside a function (or use a goto to skip it), which probabily caused the crash, in case it was running some code or something... i will re-investigate that

and yes that works on linux now... on windows, the internal variable is not there (different name? not used? unecessary? need external?), but as it does not crash or fail without that for now i will keep that for linux only, until i check the source of the library, i will workaround the status bar as well... altough its really lot of details to keep track on every new project... so they should be normalized as much as possible, but i will help with that