In order for WinFBE to be the successor to FireFly, it is important that I create a very easy to use and intuitive forms library that will allow the user to interact with Jose's WinFBX library and the Win32 api in the easiest way possible. WinFormsX is my attempt to create a dot notation style forms library. It is still in the early stages but a lot of the underlying engine is now built. Once it matures then it will make the code generation from the visual designer inside WinFBE to be easier for the user to read and understand.
I post the following code to give a simple look at how the code looks. A user could create windows applications by hand if they wish or allow WinFBE to generate the vast bulk of the code below.
WinFBE and WinFormsX are my primary focus this year and I am focused to finish it as soon as I can. I really want a full featured and easy to use editor and visual designer for FreeBASIC.
''
'' FORMTEST
'' Form test application.
''
#include once "WinFormsX\WinFormsX.bi"
'#CONSOLE ON
declare function Form1_MouseMove( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Click( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Load( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Activated( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Deactivate( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Shown( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_FormClosing( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_FormClosed( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Move( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_Resize( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_GotFocus( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_LostFocus( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_KeyDown( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_KeyPress( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
declare function Form1_KeyUp( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
''
'' Define the form (no child controls for this test)
''
type TFORMMAIN extends wfxForm
private:
public:
' Controls
' Normally we would define our child controls.
' For example:
'
' Label1 as wfxLabel
' StatusBar as wfxStatusBar
declare constructor
END TYPE
''
'' Use the Constructor to define the properties and assign methods
'' to the form and child controls.
''
constructor TFORMMAIN
' Add the form to the global application collection
Application.Forms.Add(ControlType.Form, @this)
' Set the properties of the form
with this
.Size = 600, 400
.StartPosition = FormStartPosition.CenterScreen
.Text = "Form1"
.Name = "Form1"
.OnClick = @Form1_Click
.OnResize = @Form1_Resize
.OnMouseMove = @Form1_MouseMove
.OnLoad = @Form1_Load
.OnActivated = @Form1_Activated
.OnDeactivate = @Form1_Deactivate
.OnShown = @Form1_Shown
.OnFormClosing = @Form1_FormClosing
.OnFormClosed = @Form1_FormClosed
.OnMove = @Form1_Move
.OnGotFocus = @Form1_GotFocus
.OnLostFocus = @Form1_LostFocus
.OnKeyDown = @Form1_KeyDown
.OnKeyUp = @Form1_KeyUp
.OnKeyPress = @Form1_KeyPress
end with
END CONSTRUCTOR
'' Define a global variable that will allow access to the form and controls
dim shared Form1 as TFORMMAIN
''
'' Define the various methods that the application will respond to.
'' User code will go into these methods in order to make the application work.
''
function Form1_Load( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form Load"
function = 0
end function
function Form1_Activated( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form Activated"
function = 0
end function
function Form1_Deactivate( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form Deactivate"
function = 0
end function
function Form1_Shown( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form Shown"
function = 0
end function
function Form1_FormClosing( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form FormClosing"
function = 0
end function
function Form1_FormClosed( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form FormClosed"
function = 0
end function
function Form1_GotFocus( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form GotFocus"
function = 0
end function
function Form1_LostFocus( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form LostFocus"
function = 0
end function
function Form1_Move( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
dim pt as wfxPoint = sender.Position
sender.Text = "Form Move (x,y) = (" & pt.x & ", " & pt.y & ")"
function = 0
end function
function Form1_MouseMove( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
sender.Text = "Form MouseMove (x,y) = (" & e.x & "," & e.y & ") Buttons: " & e.Buttons
function = 0
end function
function Form1_Resize( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
dim size as wfxSize = sender.Size
sender.Text = "Form Resize (x,y) = (" & size.Width & " x " & size.Height & ")"
function = 0
end function
function Form1_KeyDown( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form KeyDown "; e.KeyChar
function = 0
end function
function Form1_KeyUp( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form KeyUp "; e.KeyChar
function = 0
end function
function Form1_KeyPress( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
? "Form KeyPress "; e.KeyChar
function = 0
end function
function Form1_Click( byref sender as wfxForm, byref e as EventArgs ) as LRESULT
' Print the properties of the form to the console window
' In addition to using the "sender" object we could also have referred to the
' form properties through use of the global shared Form1 variable.
dim pt as wfxPoint = sender.Position
dim size as wfxSize = sender.Size
dim clientsize as wfxSize = sender.ClientSize
? "Name: "; sender.Name
? "Text: "; sender.Text
? "Parent: "; sender.Parent
? "Background: "; sender.Background
? "Enabled: "; sender.Enabled
? "Visible: "; sender.Visible
? "Left: "; sender.Left
? "Top: "; sender.Top
? "Width: "; sender.Width
? "Height: "; sender.Height
? "Size: "; size.Width; " x "; size.Height
? "ClientSize: "; clientsize.Width; " x "; clientsize.Height
? "Position: "; pt.x; ", "; pt.y
? "WindowState: "; sender.WindowState
? "StartPosition: "; sender.StartPosition
? "BorderStyle: "; sender.BorderStyle
? "MinimizeBox: "; sender.MinimizeBox
? "MaximizeBox: "; sender.MaximizeBox
? "ControlBox: "; sender.ControlBox
? "IsMainForm: "; sender.IsMainForm
? "IsModal: "; sender.IsModal
?
function = 0
end function
''
'' Main code for the application.
''
Application.Run(Form1)
' Pause at the end so we can see the last messages in the console window
sleep
(Edit: Update code example to include more event handling and easier EventArgs handling).
Hi )Paul,
Downloaded, installed as recommended, and ran test program - works OK. Your install instructions, I don't think you mean to copy the whole folder, just the src folder to the fb inc folder. This is getting a bit messy, program bits and pieces all over the place. Anyway, looking good, somewhat like c#. I expect I'll manage to break it, so stand by for hassle...
Seriously, well done.
Thanks, Ray
edit - spoke too soon, now comes up with compile error, can't open rc file. Funny, it worked once, a number of times on the test form. Then restarted tried others, button, etc., rc error, and also for same original form.
Thanks Ray, I just uploaded new code a few minutes ago with the ButtonTest example. You are right, just the files in the src folder to \inc\WinFormsX I will fix that documentation mistake.
FYI,
[1.5.9]
FreeBASIC Compiler - Version 1.06.0 (11-03-2017), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
compiling: C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.bas -o C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.c (main module)
C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.bas(55) error 18: Element not defined, Add in '.Panels.Add'
Same result in 1.5.7. Both Form and Label examples compile OK in 1.5.7 and 1.5.9.
....yes, I know about the StatusBar example. I probably shouldn't have uploaded that one because it is a work in progress trying to get the .Panels(index) and .Panels.Add differing syntax to work.
Quote from: SeaVipe on February 07, 2018, 03:12:10 PM
FYI,
[1.5.9]
FreeBASIC Compiler - Version 1.06.0 (11-03-2017), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
compiling: C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.bas -o C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.c (main module)
C:\WinFBE-1.5.9\Examples\WinFormsX\StatusBarTest.bas(55) error 18: Element not defined, Add in '.Panels.Add'
Same result in 1.5.7. Both Form and Label examples compile OK in 1.5.7 and 1.5.9.
I fixed this by changing references to the panel collection by using the variable "Panels" and to a specific panel by using the variable "Panel()" as can be seen in the following code snippet. I have updated GitHub.
with this.StatusBar
.Parent = @this
.SizingGrip = false
' Add 3 statusbar panels
for i as long = 0 to 2
.Panels.Add
NEXT
.Panel(0).Text = "Panel1"
.Panel(0).Width = 120
.Panel(1).Text = "Panel2"
.Panel(1).Width = 200
.Panel(2).Text = "Panel3"
.Panel(2).AutoSize = StatusBarPanelAutoSize.Spring
END WITH
this.Controls.add(controltype.StatusBar, @this.StatusBar)
Hi Paul, Not sure how helpful this is but "Panel(n)" gives errors. Changed to "Panels(n)" and I only get the .Add error.
Looks like you are using the correct new StatusBarTest.bas code but maybe you are not using the latest copies of the library code itself? The latest repository code has newer "wfxStatusBar.bi" and "wfxStatusBar.inc" files. Make sure you download and overwrite the ones that you currently have in your \inc\winformsx folder.
If I were you, I would delete the contents of your \inc\winformsx folder every time you download the code from GitHub.
I compile here with no errors in either 32 bit or 64 bit.
still stuck. downloaded and installed as requested. iirc somewhere there was a reference to add something to the compile options a .rc file I think. I know nothing about such things, can't find the ref - which I thought was in the documents. Anyway compiler log file says {error 80: Invalid command-line option, "C:\Program Files (x86)\FreeBASIC\inc\WinFormsXDOWNLOADED\examples\TMPEDC7.tmp"}
Any suggestions? In Winfbe there are a number of build configuration options - any specific one needed? I think i added whatever.rc to the compiler options there, but it is not there now...
edit to say - Sorted! ( the resource.rc is in the comments at prog beginning!!!! and you can't run it if the .bas program is in the same path as freebasic compiler. Works Ok if on desktop, or in user folder. where admin? rights not needed.
Now, when are we getting the gui to play with?
Thanks, Paul. Deleted everything and started from scratch. Works without errors.
Make sure you have the latest version of WinFBE installed (1.5.9). That version allows for a new code compiler directive called #RESOURCE that makes working with the resource file easier than adding to the compile options. In the test file "ButtonTest.bas" you will see this code that shows that #RESOURCE directive in action:
' When compiling, be sure to include the file "resource.rc". In WinFBE, this can be done
' via the Compiler Setup / Additional Compiler Settings, or using the #RESOURCE code
' directive as shown below.
'#CONSOLE ON
'#RESOURCE "resource.rc"
Also, from your compiler error it looks like you are using WinFBE's "Quick Run". Try doing a normal compile and run instead.
The instructions you are looking for are in (1) The "docs" folder in the *.md files (these are called markdown files and I will use them to generate HTML code or PDF files later.; or, (2) The main GitHub page has the instructions listed as well (towards the bottom of the webpage): https://github.com/PaulSquires/WinFormsX
.... I just read both of your posts :) Awesome that you guys got it figured out and working. With people actually using and testing the code makes it more motivating for me to develop faster.
Not much sense building the GUI visual designer in WinFBE until most of this library is complete because it is kind of a chicken and egg scenario.
If I don't know what code is being generated...then how can I build the GUI to generate the unknown code :)
Hi Paul, any of the other inc's working - e.g. textbox, linked list, whatever. I'm sort of thinking of programmatically generating the forms, at least the simple ones. It would be quicker than sliding shapes around the screen, I reckon. e.g. a form, or even command line - size of form, number of buttons, number of text boxes, then code generated so that they get spaced around the form in a more or less predefined way. The form could then be titivated up in a gui editor, if needed. I don't want to spend too much time on this, if the list/text binaries are not yet prime time. It was easy enough to alter your button test, for example, cutting and pasting three blocks of code, and altering 1's to 2's. Have you an explanation of how you are making this work, although I've more or less worked out as much as i need. The basic stuff, I'm finding out, e.g. quick compile does not save an .exe - wasted a bit of time wondering where the .exe had disappeared to. I need to get this organized better. Storage always has been, always will be a problem, as are interfaces, digital in an analogue world, etc.
I've been randomly going through some of the button actions - resizing, moving, etc. A simple form1.button1.hide inside the the button2_click function hides button1 as expected, but a similar form1.button1.show in the button3_click function does not make it reappear. Is that correct behavior?
visible true/false are ok, even hide then visible=true works.
How to change button background colors?
Quote from: raymw on February 08, 2018, 10:52:40 AM
Hi Paul, any of the other inc's working - e.g. textbox, linked list, whatever.
Nope. So far only the Form, Button, Label and StatusBar has any real working code.
QuoteI'm sort of thinking of programmatically generating the forms, at least the simple ones. It would be quicker than sliding shapes around the screen, I reckon. e.g. a form, or even command line - size of form, number of buttons, number of text boxes, then code generated so that they get spaced around the form in a more or less predefined way.
Seems like a lot of work. :) I'd wait until the visual designer is finished or simply continue to hand code.
Quote from: raymw on February 08, 2018, 12:43:17 PM
I've been randomly going through some of the button actions - resizing, moving, etc. A simple form1.button1.hide inside the the button2_click function hides button1 as expected, but a similar form1.button1.show in the button3_click function does not make it reappear. Is that correct behavior?
visible true/false are ok, even hide then visible=true works.
When a valid control exists (ie. it has a Window handle) then the Show/Hide methods should work the same as changing that control's Visible property between True and False.
Quote
How to change button background colors?
You can't change the background colors of a standard Windows button. The button would have to ownerdrawn. This has been the case for every standard windows button since the beginning of time. :)
Quote from: Paul Squires on February 08, 2018, 04:38:26 PM
When a valid control exists (ie. it has a Window handle) then the Show/Hide methods should work the same as changing that control's Visible property between True and False.
I found the problem. Easy fix. Will be in GitHub upload later tonight.
QuoteYou can't change the background colors of a standard Windows button. The button would have to ownerdrawn. This has been the case for every standard windows button since the beginning of time.
well, I guess I can use a label instead of a button. Colours are useful for things like 'emergency stop', and simulation of m/c control panels, etc. I can't remember what I did in VS/C#.
No big deal. Is it possible to turn off the predictive text/hint, for button.background, and similar?
Quote from: raymw on February 08, 2018, 06:57:15 PM
No big deal. Is it possible to turn off the predictive text/hint, for button.background, and similar?
I put Background as part of the base Control class and Button extends from that Control class. That's why it appears. Technically, you're right, the Control class should only contain properties that are common to EVERY control. Not sure if there is a way to selectively select some elements of the class and not others.
I have uploaded new code to GitHub a few minutes ago.
Now that the form and a couple of controls exist, I will create documentation for them to explain what properties, methods and events are valid for each control. That is important because I don't want to get too deep into development and then have to document everything later (I am quite lazy when it comes to documentation). I have found a great free markdown editor called Typora (https://typora.io/) and can easily create PDF's from it.
I've been looking at buttons, what a sad life... Anyway, in your editor, when the compiler results window shows, the 'OK' button changes background color (to light blue) when selected. The winformx buttons change the outline when clicked. Here https://msdn.microsoft.com/en-us/library/windows/desktop/dn742402(v=vs.85).aspx (https://msdn.microsoft.com/en-us/library/windows/desktop/dn742402(v=vs.85).aspx) the backgrounds are shaded and borders are different. Now, it seems that more recent (win 8?) 'cleaner page' concept does not use buttons with borders, but labels. I seem to remember, from somewhere, that the standard message box buttons changed, depending on the version of windows being used. I checked back in my c# prog. and found that the .net button allows background colors.
Anyway, you've an hbackbrush get, which returns a value for the button, but no set equivalent listed, afaik. Also, no fonts?
Hi Ray, yes command buttons have changed over the years but that is mostly due to the Windows version and if theming has been enabled for the application. For our examples, we include resource.rc which then includes the theming manifest file that allows for the blue/shade/borders stuff. Background colors in .Net buttons are possible because those buttons are not pure Win32 api buttons but rather custom controls built for .Net. We could do something similar for example using Jose's XP button. We could make that button the standard/default button for WinFormsX and then we'd have a lot more styling options than the default operating system based button. Certainly something to ponder and consider especially at this early stage of development.
wrt the font, firefly has font choices. I think it would be good to have custom controls if possible. I guess it depends on the end user as to whether standardization is desirable. As well as colorful buttons, I would have an interest in the possibility of text or list boxes, with integrated labels. Of course, this all could be added later, provided allowances were made early in your development. I'm not sure about defaults. Whether they should be simple, so that a quick and dirty? solution can be made, then tart it up afterwards, or spend time in initial micro programming the detailed appearance, and delay the completion of the answer. I'm tending towards initial simplicity, almost to the extent of having a standard size for a default button, just specify location and text. But then, a fully design-able button could have suitable defaults to achieve the same simplicity of use, and allow adjustments later on. I guess, from your point of view, writing the code to generate all this, it would probably be simpler to only create the basic features.
Anyway, fwiw, the buttons work ok, as do the labels as far as I can tell. Looking forward to text boxes, maybe options and lists, then I can try my next project.
Thanks Ray - also the benefit of using a custom control button (like Jose's XP button) as the standard base button for the library would be that button also handles graphics and text/graphics. It is kind of an all-in-one solution. That button could be further extended to use gdiplus so that images other than bitmaps and icons (such as PNG images) could be used. That would be awesome.
I haven't implemented the font stuff yet because I want to do it via a class and wanted to have a couple of existing controls firsts to give me an idea of how best to implement it.
Once the guts of the library is there then adding additional controls almost becomes trivial.
Hi Paul, new examples work properly with resource.rc as the last param in Compiler Setup / Additional Compiler options. But when removed and uncomment #RESOURCE "resource.rc", I get the following error:
FreeBASIC Compiler - Version 1.06.0 (11-03-2017), built for win64 (64bit)
Copyright (C) 2004-2016 The FreeBASIC development team.
standalone
target: win64, x86-64, 64bit
compiling: C:\WinFormsX-master\examples\StatusBarTest.bas -o C:\WinFormsX-master\examples\StatusBarTest.c (main module)
C:\WinFormsX-master\examples\StatusBarTest.bas(19) error 17: Syntax error, found 'RESOURCE' in '#RESOURCE "resource.rc"'
You are not supposed to uncomment #RESOURCE.
WinFBE scans the code for "compiler directives" and these directives start with the comment ' character.
'#RESOURCE
'#CONSOLE
Those are the only two directives that exist at this point.
Also, I have uploaded 2 PDF's to GitHub. Tomorrow I will create more PDFs for each of the form/controls.
Hi Paul, at the moment, I have no resource.rc in the compiler command line, and if I remove the '#resource "resource.rc" from the program, it apparently compiles and runs the same. That's on w10, 32bit, freebasic 1.05. To me, it looks as if the resource.rc refers to an xml file with various windows versions. Is it safe to have a comment that should not be removed? . Thanks for the pdf's, etc.
Thanks.
Similar in syntax to a Metacommand?
'$Include - Alternate form of the #include directive.
'$Dynamic - Alternate form of the Option Dynamic statement.
'$Static - Alternate form of the Option Static statement.
'$Lang - Alternate form of the #lang directive.
Quote from: raymw on February 09, 2018, 09:52:24 PM
Hi Paul, at the moment, I have no resource.rc in the compiler command line, and if I remove the '#resource "resource.rc" from the program, it apparently compiles and runs the same. That's on w10, 32bit, freebasic 1.05. To me, it looks as if the resource.rc refers to an xml file with various windows versions. Is it safe to have a comment that should not be removed? . Thanks for the pdf's, etc.
Yes, it will run without the resource but the app not be correctly themed or dpi aware. Every app should have a manifest and that resource loads the manifest.
More pdfs to come :)
If you what more explanations, etc that you think should be in a pdf then please let me know. I want to get off on the right track with regards to documentation. If I document as I develop then the task won't be so difficult than if I waited until the development was complete.
Quote from: SeaVipe on February 09, 2018, 10:04:36 PM
Thanks.
Similar in syntax to a Metacommand?
'$Include - Alternate form of the #include directive.
'$Dynamic - Alternate form of the Option Dynamic statement.
'$Static - Alternate form of the Option Static statement.
'$Lang - Alternate form of the #lang directive.
Yes, that's basically correct. I could have called it anything but chose to use '#RESOURCE. Hopefully that doesn't become confusing to users.
> If I document as I develop then the task won't be so difficult than if I waited until the development was complete.
This is what I always do. The help for WinFBX has about 4,200 entries. Imagine that I had to write all of them at once.
4,200 entries :) That's a lot of work!
I have to say though that using Markdown language (and Typora or a regular text editor) is really easy and I find less formatting issues than using a dedicated HTML Help editor. Just a couple of problems with pdf output and tables bumping to second page when it should not.
I have uploaded new code and docs to github.
Maybe a Quick Start note just to be on the safe side.
Perhaps user selectable colouring for such items?
Quote from: Paul Squires on February 09, 2018, 10:18:32 PM
Quote from: SeaVipe on February 09, 2018, 10:04:36 PM
Thanks.
Similar in syntax to a Metacommand?
'$Include - Alternate form of the #include directive.
'$Dynamic - Alternate form of the Option Dynamic statement.
'$Static - Alternate form of the Option Static statement.
'$Lang - Alternate form of the #lang directive.
Yes, that's basically correct. I could have called it anything but chose to use '#RESOURCE. Hopefully that doesn't become confusing to users.
To be honest, in most cases a WinFormsX application will be created using a visual designer through a WinFBE project. When part of a WinFBE project, the resource will be identified as such and will be automatically part of the project compile. There would be zero need for the directive in those cases.
In the short one file examples that I have posted to test WinFormsX features, I use the directive in order to make compiling a little easier (not having to add it to WinFBE's compiler options). It also saves me from having to create a formal project for every code example.
Quote from: Paul Squires on February 10, 2018, 04:34:38 PM
To be honest, in most cases a WinFormsX application will be created using a visual designer through a WinFBE project. When part of a WinFBE project, the resource will be identified as such and will be automatically part of the project compile. There would be zero need for the directive in those cases.
In the short one file examples that I have posted to test WinFormsX features, I use the directive in order to make compiling a little easier (not having to add it to WinFBE's compiler options). It also saves me from having to create a formal project for every code example.
Understood. Thanks for the explanation. Looking forward to the Visual Designer beta...
Cleaned up some statusbar code, added new pdfs, added start of the cryptox password manager sample application.
...working on the ListBox. Hope to have that one in the library pretty soon.
Thanks, Paul,
Will there be some sort of a Grid example?
I think a grid is essential. Not many options at this point other than Jim's version. Maybe I'll adapt that version. A printing library will be needed as well.
I have had bad headaches these past two days so I am a little behind. I can't stare at the screen for more than an hour before my head hurts. I have an eye examination booked..... getting old.
There's a little island just south of you that would surely help with the eye strain - Barbados - PCs not allowed!
:) lol, count me in. I could use a little bit of sun and relaxation at this time of year.
;) LOL, you guys have all the good islands! The only one south of me is Robben Island, and that is a jail.
ListBox code uploaded to GitHub.
I think top menu will be the next control to implement.
Hi Paul, testing out the text box. Should the enter key/carriage return, whatever it's called these days, be counted as a key press? It's often used to signify end of data entry and skip to next field, but e.keychar shows no value.
Hi Ray,
ENTER key would not be caught in the KeyPress event but rather the KeyDown or KeyUp event as per the following:
function Form1_Text1_KeyUp( byref sender as wfxTextBox, byref e as EventArgs ) as LRESULT
? "Text1 KeyUp: "; e.KeyCode ' ENTER = 13
function = 0
end function
As a hobbyist, I bought into FireFly and PowerBasic some years ago.
While now as a retired individual, but, still a programming hobbyist; I find the efforts of Paul, Jose and the FreeBasic community, absolutely astounding! Thank you ALL!
Is there a 'Donate' button somewhere that points towards these individuals/groups?
Thanks Peter! That is very nice of you to say. :)
No need for donations but thanks for the thought though. Participating and using the software and tools is thanks enough.
Hi Paul,
testing the form example, e.keychar does not return a character, (but keyup and keydown are detected), and keypress appears to not elicit any response. I've never needed to enter characters directly on a form, so I wonder why they are there.
Best wishes,
Ray
Hi Ray, I'll probably re-work the way keys are captured so that all keys will be available through the KeyPress event rather than some through that event and others just throught KeyUp/KeyDown. The are situations where users want to intercept key presses for a Form - it was a feature in Visual Basic and now .Net and FireFly Visual Designer users asked for it as well.
hi paul:
Does winformX stop developing? We still look forward to winfbe's visual interface designer
Still working on it. Hope to have a workable visual designer soon for people to test.
Thanks, Paul! Much appreciated.
Clive Richey