I miss VB...

[MichaelW]

wxWdigets (and to a lesser extent GTK+, but that has Glade to help you out) is *much* less complex API than native Win32 for building GUI apps…

Just about everything is much less complex than the Windows API, and you missed my point. With wxWdigets or similar or even VB you must learn a complex API, that typically is more or less poorly documented, and this knowledge is typically not portable to other such tools, even under Windows. Within my experience, getting the appearance and functionality that I want from one of these tools frequently requires knowledge of the Windows API. Instead of learning one of these tools and then learning how to work around its shortcomings, my time is better spent extending my knowledge of the Windows API, learning to use it efficiently, and developing code to automate the most common tasks.

The main advantage with wxWidgets is that it uses the controls from the underlying GUI anyway, so it acts as a handy abstraction layer and your end-user sees something which looks and acts in the way they expect.

It uses only the controls that are common to all of the supported platforms. And in my view unnecessary abstraction is something to be avoided.

[osiyo53]

I don't see how a GUI would appear crucial to an FB user unless you come from a VB background.

Hmmm.

I've used VB. Tho, the last time was many years ago.

I often write simple console mode utilities. Especially if they're things which will be used only by myself or by certain select others (who're all folks who are used to command line utilities).

However, there are APPLICATION users out there in the world (these days, that means the vast majority of folks) who're simply not comfortable with console mode apps.

So sometimes I make my apps with a GUI interface. Particularly if they're geared towards those not comfy with the keyboard and/or console mode screens.

Now, I'm not a full time programmer of the sort most of you would be familiar with, I do specialty type programming for controlling mechanical and electrical equipment. Which involves proprietary programming languages, very specialized type programming, etc.

I'm not as "up to speed" as concerns general purpose programming as many of you folks in this forum are. In fact, many of the discussions you folks have about this or that technicality of method or procedure for doing this thing or the other might as well be written in Greek as far as I'm concerned. Often enough, I've no clue as to what's being discussed; or why I'd want to do that; or even what it'd be useful for ... much less understand the various arguments. Nor am I familiar with the Windows API except in a very superficial way.

So, when I do want or need to write an app which has a GUI interface to it, I want a KISS method of doing this.

It's simple, when I'm doing an app I'm intent upon making a program that does something useful. (To me, at least) I'm concentrating on the meat of the app, that part of it which will accomplish a useful task. I don't want to, and don't intend to ... spend hours figuring out how to put a simple form on the screen with a few edit boxes and some buttons, get em all lined up so they look reasonably neat and orderly. And do wish to spend a lot of time typing dozens (or hundreds) of commands and statements ... just to make a simple Windows form with a few buttons and edit boxes.

Could. Could also spend the time to learn the details of using Windows API calls in order to accomplish this. (Or WX or GTK or etc)

But ... I don't want to. And I'm simply not going to.

I want to spend what little brain power I have on the meat of the matter ... the core of the program which actually does whatever it is I'm trying to get it to do.

I think this point is what some of the posters are trying to make, when they're asking if there are any SIMPLE GUI libraries available.

If they were interested in the GUI itself, the complex coding and understanding it ... they would probably figure out how to make their own library of routines. Or learn to use the Windows API (or WX or GTK, or etc). Which MAY seem simple to some of you guys. But to me, and I'm sure it's the same with others, while I can muddle my way slowly thru such code ... it makes my head hurt. And I get impatient because that's not the part of programming, nor the type of coding, I'm actually interested in. It's not that I CAN"T understand thoses things. The issue is I don't want to spend the time or sweat equity needed. It's not the part of programming I enjoy.

I don't want to, nor do I enjoy, spending a lot of time and effort to make and display a clickable button. I want, and enjoy most, spending my time on the coding of the routine that'll do something when that button is clicked.

For those like me, there is an interest in a simple to use GUI creation library.

Not that I'm asking for such myself. <Shrug> I'm not in the habit of asking others to do a lot of sweating for me. I figure somebody either will or they won't make such, all on his/her own free will because that's the sort of challenge/coding that person likes to do.

In the meantime, whenever I need to make an app with a Windows type GUI interface for the user, I use alternate means.

If the code is not computationally intense (speed is not a big issue) but I want a GUI interface on the app, I tend to use Rapidq.

If more speed is needed, I'll merge FreeBasic routines with Rapidq code using techniques developed by some of the Rapidq users over in that forum. It's kind of like having the best of both worlds. FreeBasic's speed, compact code, extra abilities, etc ... merged with Rapidq's easy to design and use GUI elements.

Or, in some cases I have made console mode command line utilities in the past, which I later decided to slap a GUI interface upon. And rather than rewrite everything, just made a "front end" GUI for the console mode app using AutoHotKey. Which has some easy methods for making message boxes, buttons, and so forth. Along with easy to use "Send Key" commands and the like. (I'll admit it, I'm lazy) And AutoHotKey scripts can be compiled into stand-alone executables.

In a previous post in this thread, another poster posted what he thought to be simple, easily understood code for popping up a dialog box, a button, etc. And, to be fair, compared to many other examples I've seen, it was a cleaner and easier method.

But not nearly so easy to read and understand as Rapidq GUI code, for instance.

Myself, I use Rapidq's original form designer to design a screen, put in appropriate buttons, edit boxes, and so forth. And to set SOME of the attributes of each of the objects. This being a simple and direct process. Pretty much a "no brainer". Which suits me fine as I'm not the brightest apple on the tree by any means. I also assign events within the form designer. Then tell it to "Code It". Which it does quickly and efficiently.

Then copy and paste the resulting code over to my usual text editor. And close the form designer.

I don't use the rest of the Rapidq IDE at all. Have no use for it. Just gets in my way. Pretty much the same as back when I was using VB. I'm a line coder at heart. Then I hand code the subroutines that're called when the appropriate event occurs (a button is clicked or whatever).

The following is a very simple example. The code is not the complete code of the final product I made, I cut parts out as they're not important to this discussion. And the rest of the code was very long.

The only point is for me to show what SIMPLE GUI creation can look like, that's pretty durned easy to understand. And in this case the majority of what you'll see was auto-generated by Rapidq's form designer. All I had to do was add the code down in the subroutines.

I'm not trying to convert anyone to Rapidq. Not the point. Just trying to show yah what I think the other folks who're asking for SIMPLE to use GUI libraries are looking for.

Code: Select all

$APPTYPE GUI
$TYPECHECK ON

$INCLUDE "c:\rapidq\include\RapidQ.inc"
$ESCAPECHARS off
$OPTION ICON "star.ico"

DECLARE SUB CalcBtnClick (Sender AS QBUTTON)
DECLARE SUB ResetBtnClick (Sender AS QBUTTON)

DIM RealNum as Single
DIM CVNum as Single
DIM MXNum as Single
DIM NewNum as Single
DIM TempNum as Single

CREATE Form AS QFORM
    Caption = "DDC Controller Universal Input Re-Scaling Calculator"
    Width = 579
    Height = 418
    Center
    CREATE Label1 AS QLABEL
        Caption = "Re-scale Input"
        Left = 218
        Top = 26
        Width = 73
        Height = 21
    END CREATE

    'Get the real, measured value ------------------------------------------
    CREATE RMV_Label AS QLABEL
        Caption = "Real Measured Value : "
        Left = 137
        Top = 60
        Width = 114
    END CREATE
    CREATE RMV_Edit AS QEDIT
        Text = "0"
        Left = 257
        Top = 57
        Height = 19
        InputMask = "##########"
    END CREATE

    'Get the current value shown by the input ------------------------------------------
    CREATE CV_Label AS QLABEL
        Caption = "Input Current Value : "
        Left = 148
        Top = 120
        Width = 103
        Height = 14
    END CREATE
    CREATE CV_Edit AS QEDIT
        Text = "0"
        Left = 257
        Top = 118
        Height = 19
        InputMask = "##########"
    END CREATE

    'Get the current max scale for the input ------------------------------------------
    CREATE MX_Label AS QLABEL
        Caption = "Input Current Max Scale : "
        Left = 125
        Top = 180
        Width = 125
        Height = 14
    END CREATE
    CREATE MX_Edit AS QEDIT
        Text = "0"
        Left = 257
        Top = 177
        Height = 19
        InputMask = "##########"
    END CREATE

    'Show the new max scale for the input ------------------------------------------
    CREATE New_Label AS QLABEL
        Caption = "Input New Max Scale : "
        Left = 137
        Top = 240
        Width = 113
        Height = 14
    END CREATE
    CREATE New_Edit AS QEDIT
        Text = "0"
        Left = 257
        Top = 237
        Height = 19
	ReadOnly = True
    END CREATE

    'CALCULATE button ------------------------------------------
    CREATE CalcBtn AS QBUTTON
        Caption = "Calculate"
        Left = 73
        Top = 300
        OnClick = CalcBtnClick
    END CREATE

    'RESET button ------------------------------------------
    CREATE ResetBtn AS QBUTTON
        Caption = "Reset"
        Left = 240
        Top = 300
        OnClick = ResetBtnClick
    END CREATE

END CREATE

'Insert initialization code here

New_Edit.Enabled = False

Form.ShowModal

'--------- Subroutines ---------

SUB CalcBtnClick (Sender AS QBUTTON)
   '-- Enter your code here
   RealNum = VAL(RMV_Edit.Text)
   CVNum = VAL(CV_Edit.Text)
   MXNum = VAL(MX_Edit.Text)

   TempNum = RealNum/CVNum
   NewNum = MXNum * TempNum

   New_Edit.Text = STR$(NewNum)
   New_Edit.Enabled = True

END SUB

SUB ResetBtnClick (Sender AS QBUTTON)
   '-- Enter your code here
   RMV_Edit.Text = "0"
   CV_Edit.Text = "0"
   MX_Edit.Text = "0"
   New_Edit.Text = "0"
   New_Edit.Enabled = False
END SUB

[/code]

[cha0s]

I've never really heard anything bad about RapidQ, afaik :).

Well, besides the fact that the author stopped maintaining it... and it wasn't open source... right?

[jonbobbly]

OK, so now I think about it there are a handful of messy things that you need to do to create GUIs in wxWidgets, so I've quickly put together a set of macros in the form of an include file ("wxHelper.bi") as follows:

Code: Select all

#include once "wx-c/wx.bi"

#macro CreateWindow( _object, _title, _width, _height )
    _object = wxFrame( )
   	wxFrame_Create( _object, 0, -1, _title, wxSize( _width, _height ), wxSize( -1, -1 ), wxDEFAULT_FRAME_STYLE, "frame" )
#endmacro

#macro AddButton( _parent, _object, _caption, _x, _y, _click_event )
    dim as wxButton ptr _object = wxButton()
   	wxbutton_create( _object, _parent, 1001, _caption, wxsize( _x, _y ), wxSize( -1, -1 ), 0, 0, 0 )
   	wxEvtHandler_proxy( _object, @_click_event )
   	wxEvtHandler_connect( _object, wxEvent_EVT_COMMAND_BUTTON_CLICKED(), 1001, -1, 0 )
#endmacro

#macro InitWx()
    dim shared as wxApp ptr app
    
    function app_onexit () as integer
        function = wxApp_OnExit( app )
    end function
#endmacro

#macro StartWx()
    function app_oninit() as integer
#endmacro

#macro RunWx()
        function = wxApp_OnInit( app )
    end function
    
    app = wxApp( )
    wxApp_RegisterVirtual( app, @app_oninit, @app_onexit)
    wxApp_Run( 0, 0 )
    end 0
#endmacro

#macro AddPanel( _parent, _object )
    dim as wxPanel ptr panel = wxPanel()
   	wxPanel_Create( _object, _parent, -1, 0, 0, 0, 0 )
#endmacro

#macro MsgBox( _message )
    wxMsgBox( 0, _message, "", 0, wxSize( -1, -1 ) )
#endmacro

#macro CloseWindow( _object )
    wxWindow_Close( _object, 0 )
#endmacro

#macro ShowWindow( _object )
    wxWindow_Show( _object, 1 )
#endmacro

#macro DimWindow( _object )
    dim shared as wxFrame ptr _object
#endmacro

#macro DeclareCallBack( _name )
    declare sub _name (byval event as wxEvent ptr, byval iListener as integer)
#endmacro

#macro CallBack( _name )
    sub _name (byval event as wxEvent ptr, byval iListener as integer)
#endmacro

#macro EndCallBack()
    end sub
#endmacro

Which allows you to do the following:

Code: Select all

#include once "wxHelper.bi"

InitWx()

DimWindow ( mywin )

CallBack( button_clicked )
    MsgBox ( "Hi" )
    CloseWindow ( mywin )
EndCallBack()

StartWx()
    CreateWindow ( mywin, "My Window", 400, 200 )
    AddPanel ( mywin, panel )
    AddButton ( panel, exitbutton, "Click Me", 160, 90, button_clicked)
    ShowWindow ( mywin )
RunWx()

Which I hope is the sort of thing people have been looking for in this thread.

I've only put together macros for the basics to match jonbobbly's pseudo-code, but I'll expand this over the next week so it's more complete and useful for writing actual GUI apps.

This is almost exactly what I'm looking for! Please keep working on it. I'm really interested in creating a GUI interface for a text-adventure I'm working on, so if you could add macros for for working with text boxes and menus, I could essentially use this to completely create the GUI. Thanks for the cool code! :D

[eodor]

Want powerful GUI, then use Delphi.

[ciw1973]

This is almost exactly what I'm looking for! Please keep working on it. I'm really interested in creating a GUI interface for a text-adventure I'm working on, so if you could add macros for for working with text boxes and menus, I could essentially use this to completely create the GUI. Thanks for the cool code! :D

The above only took about 10 minutes, and there'll need to be a bit more planning if I'm going to do this properly, so it's going to be the weekend before I'll get chance to do anything more. I'll certainly try and get all of the essential stuff done for you then though.

I've also got another idea which will allow the design of screen layouts in ASCII in the same way we used to do it in DataFLEX many moons ago, but with code to present this as a proper GUI, more than likely using wxWidgets. This sort of approach will definitely be the best bet if you want to put together simple functional GUIs quickly in code, and could be modified quite easily to allow different GUI toolkits for presentation.

Guess that'll be something to start the following weekend, which will mean there's no way I'm going to get anything written for my game competition.

Oh, and I agree entirely with eodor, Delphi is a magnificent way to quickly build good GUI apps, it's just a pity the standard controls are so basic, which is why I always used the DevExpress control and grid component suites with it. Still it's much better than VB in my book, allows you to build a fully functional database app with little or no coding, and produces single .EXE files which don't need installing as such.

[jonbobbly]

This is almost exactly what I'm looking for! Please keep working on it. I'm really interested in creating a GUI interface for a text-adventure I'm working on, so if you could add macros for for working with text boxes and menus, I could essentially use this to completely create the GUI. Thanks for the cool code! :D

The above only took about 10 minutes, and there'll need to be a bit more planning if I'm going to do this properly, so it's going to be the weekend before I'll get chance to do anything more. I'll certainly try and get all of the essential stuff done for you then though.

I've also got another idea which will allow the design of screen layouts in ASCII in the same way we used to do it in DataFLEX many moons ago, but with code to present this as a proper GUI, more than likely using wxWidgets. This sort of approach will definitely be the best bet if you want to put together simple functional GUIs quickly in code, and could be modified quite easily to allow different GUI toolkits for presentation.

Guess that'll be something to start the following weekend, which will mean there's no way I'm going to get anything written for my game competition.

Oh, and I agree entirely with eodor, Delphi is a magnificent way to quickly build good GUI apps, it's just a pity the standard controls are so basic, which is why I always used the DevExpress control and grid component suites with it. Still it's much better than VB in my book, allows you to build a fully functional database app with little or no coding, and produces single .EXE files which don't need installing as such.

Thanks a lot for your help. I am really looking forward for you code.

[srvaldez]

yes, me too :)

[Eponasoft]

As long as no one is looking for a VB-type GUI library, I do believe I could whip one up in a matter of days. It would be platform-specific though, and I would start with the Windows platform. No dependencies though, so no wx-c or GTK+ required, only plain Windows API under the hood for maximum efficiency and space.

[osiyo53]

I've never really heard anything bad about RapidQ, afaik :).

Well, besides the fact that the author stopped maintaining it... and it wasn't open source... right?

Correct, William (RapidQ's creator) went to work for Real Basic (I think that's the outfit). And I understand that Real Basic bought the rights to William's source code. So he's not free to continue the development of RapidQ.

However, William had declared the USE of the original RapidQ as free for anyone to use, for any purpose. Except that they could not sell the compiler and it's parts or claim it as their own creation.

So there are still numerous users using RapidQ.

And while RapidQ itself isn't under continued development, it has been considerably "enhanced" since development ceased.

In that numerous users have created quite a nice collection of code base for it. Whole apps with source code published, thousands of code snippets showing how to do this or that, INC files that one can include in one's own apps that make adding network functions, database access, richedit boxes with advanced functions, graphing routines, etc and so forth pretty easy even for relative newbies. Or the slow witted such as myself.

Others have made and released EXTENDED Objects that were part of the original package that give added abilities to said Objects.

Add that some users, with skills far greater than mine, have even published modified binaries of the original compiler and it's libraries that correct some bugs and faults that were in the original. Another has released directions and utilities that, for instance, allow one to combine compiled code from both FreeBasic and RapidQ into a single executable.

So that one can use RapidQ coding, which is simpler and easier to understand for doing certain sorts of things. And yet one can easily use FreeBasic compiled code within that same RapidQ app for doing those things that FreeBasic does much better.

RapidQ compiled code is not blazingly fast. In many cases, it's more than fast enough. But one does not want to try to code fast action games in it, or complex and intensive mathematical functions that need to handle lots and lots of recalculations. Thus, several RapidQ users turned to including assembly routines within RapidQ; worked out how to make DLL's with FreeBasic and callable by RapidQ; and figured out how to make the combined code (FreeBasic and RapidQ), single executables that merge the two. Which is made pretty easy thanks to Jacques.

JohnK, besides contributing valuable original code himself, also put together his RAPIDQ2.INC file and made it available. Which is his compilation and organization of the "best of" Include files gathered from numerous sources. Which when used, makes coding your apps even simpler as compared to the original RAPIDQ.INC . He also put together and organized a bunch of examples into a nice collection which makes it easy for a user to find examples of how to do many, many things a coder might like to do. He has a site where users can download these collections.

Then there is Andrew, who put together his RapidQ Documentation Project, and makes it available for download. Which is essentially a much enhanced doc/help file for using RapidQ and doing all sorts of things with it. Correcting inaccuracies, over-looked subjects, and so forth that were in the original docs. Plus adding a bunch of stuff.

So, yes ... development of the compiler ceased several years ago ... but has continued in another sense.

RapidQ has "matured". That is to say, if one uses the resources readily available to build a library of what code and documentation is freely available out there ... a newbie or the occasional hobby programmer can find building a workable app that does something useful easier than is true with many programming languages.

In general, most of the users of RapidQ who made and distributed INC files, extended objects, code snippets, and so forth stayed pretty true to William Yu's original concept and methodology of doing these things in a way so that the final product was easily understandable and usable by newbies and amatuers, and fairly consistent in usage syntax. Pretty much shielding them from the underlying complexities of the Windows API, etc. In short, they could pretty easily understand what a section of code did, what it was useful for, and how to use it effectively. Even if they didn't have the knowledge or skills to understand the raw INC file code itself (for example). The nice "consistency" adhered to by many of the users contributed to RapidQ's popularity, I'm sure. KISS is a good thing, particularly for newbies and amatuers/occasional hobby programmers.

FWIW, one finds a lot of ex- and current RapidQ users in this forum. Others have joined the HotBasic group. HotBasic being a near RapidQ clone, with improvements and continued development. Tho neither free nor open source.

Myself, for a living as I've said before I program in highly specialized and propriety programming languages for machine control. Often in languages that're very similar to a subset of QBasic 1.1 (the interpreter version) or GWBasic. With added commands and statements and functions that're specific to the control of mechanical and electrical devices.

For other programming I do, which is pretty basic stuff such as specialized calculators and file parsers, I tend to switch off between FreeBasic and RapidQ. Liking both. I don't really contribute code because the type of coding I do tends to be very specific and special purpose. And it's so BASIC that it's unlikely to be anything worth notice or usage by most of the folks who hang around this forum.

I'm here to learn, and haven't either the knowledge or the skills to make useful contributions.

[D.J.Peters]

i tested to write an QT C++ wrapper in the morning

Code: Select all

#include "qwrapper.bi"
function main()
  dim as QAPPLICATION app= Q_Application()
  dim as QPUSHBUTTON btn=Q_PushButton("Hit me!")
  Q_PushButtonResize(btn,100,30)
  Q_PushButtonShow(btn)
  return Q_ApplicationExec(app)
end function

main

same on lin and win

Joshy

here the C++ version

Code: Select all

#include <QApplication>
#include <QPushButton>
int main(int argc, char *argv[]) {
     QApplication app(argc, argv);
     QPushButton btn("Hit me!);
     btn.resize(100, 30);
     btn.show();
     return app.exec();
 }

[ciw1973]

I like QT a lot, but as I frequently end up writing small commercial applications, I use wxWidgets instead because it's completely free.

[Sisophon2001]

[quote="D.J.Peters"]i tested to write an QT C++ wrapper in the morning

Code: Select all

#include "qwrapper.bi"
<snip>

Do you have the include file to share?

Garvan

[PaulSquires]

If the FB community could build one GUI library and have most people agree that it will be the prime focus of continued development, I would be more than happy to build support for it into the FireFly Visual Designer (http://www.planetsquires.com).

I have long planned to add FreeBASIC support into FireFly, but I have been slow to do so because it means that I would have to write or co-write the library thereby taking away development time from other programming issues of mine.

FireFly Visual Designer + FreeBASIC code generation would be a free product. I think that's a good deal for the community as a whole and maybe help put to rest a lot of these GUI / VB problems (at least until an even better solution emerges).

The library would need to be WinAPI based.

Thoughts on this?

[D.J.Peters]

It was only an short test at the morning i wrote never before an C++ wrapper and it works so far you need more than only the wrapper.bi file!
"qtwrapper.bi"

Code: Select all

#IFNDEF __QTWRAPPER_BI__
#DEFINE __QTWRAPPER_BI__

#DEFINE _DF(n) DECLARE FUNCTION n CDECL LIB "QTWRAPPER" ALIAS #n
#DEFINE _DS(n) DECLARE SUB n CDECL LIB "QTWRAPPER" ALIAS #n

type QOBJECT as any
type QAPPLICATION as QOBJECT ptr
type QPUSHBUTTON  as QOBJECT ptr
#IFDEF __FB_DEBUG__ 
# LIBPATH "debug"
#ELSE
# LIBPATH "release"
#ENDIF

#inclib "qtwrapper"
_dS(Q_Application) (byval argc as integer,byval argv as byte ptr ptr) 'as QAPPLICATION
_dF(Q_ApplicationExec) as integer

_df(Q_PushButton) (byval as string) as QPUSHBUTTON
_ds(Q_PushButtonResize) (byval btn as QPUSHBUTTON,byval  w as integer,byval h as integer)
_ds(Q_PushButtonShow) (byval btn as QPUSHBUTTON)
#ENDIF

"wrapper.cpp" to create the test wrapper

Code: Select all

#ifdef QT_DLL
# define EXPORT __declspec(dllexport)
#else
# define EXPORT
#endif

extern "C" {  

QApplication * mainapp;

EXPORT void Q_Application(int argc, char *argv[]) {
  mainapp = new QApplication(argc, argv);
}

EXPORT int Q_ApplicationExec(void) {
  return (int) mainapp->exec();
}

EXPORT void * Q_PushButton(char * caption) {
  QPushButton * tmp = new QPushButton(caption);
  return (void *) tmp;
}

EXPORT void Q_PushButtonResize(QPushButton * btn,int w,int h) {
     btn->resize(w,h);
}

EXPORT void Q_PushButtonShow(QPushButton * btn) {
     btn->show();
}

"qtwrapper.pro" projectfile to generate the Makefile with qmake

Code: Select all

TEMPLATE = lib
CONFIG += dll
DEFINES += QT_DLL
TARGET =  
DEPENDPATH += .
INCLUDEPATH += .
SOURCES += wrapper.cpp

i used qmake and the MinGW environment to create QT tests on windows.

"test01.bas" fbc -s gui test01.bas

Code: Select all

#include "qtwrapper.bi"
dim as QPUSHBUTTON btn
Q_Application(0,0)         ' init the QT app object
btn=Q_PushButton("Hit Me") ' create the button widget
Q_PushButtonShow(btn)      ' make it visible
Q_ApplicationExec          ' call the GUI thread

i have no time to make an real wrapper with 1000 of C export for FB.
currently i translate ton's of Free Speed Racer fbc codes to C++
and freesound v0.4 is under havy construction too :-)

Joshy