Hi Paul,
wrt my previous labels and button testing - labels now OK but buttons not so
Function Form1_Button1_MouseDown( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
form1.button1.BackColordown=colors.red
bcount=bcount+1
form1.button2.Text= form1.button2.text + " try"+ str(bcount)
Function = 0
End Function
''
''
Function Form1_Button1_MouseUp( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
form1.button1.BackColor=colors.blue
Function = 0
End Function
blue only shows when mouse leaves button1, text in button2 does not update immediately - button2 text updates when it gets focus. I'm arguing with myself if backcolor change should be similar to label, instead of having to use backcolordown. Or, why do we need mouse clicks on labels?
When you MouseUp on the Button, the mouse is still over the button... therefore, the BackColorHot color will be used until the mouse leaves the button area. Sooooooooo.... in addition to setting the BackColor in MouseUp, you should also set the BackColorHot color.
Also, looks like you need to manually Refresh the caption. I will modify the underlying source to do the refresh when the text is set on the button.
Function Form1_Button1_MouseDown( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
form1.button1.BackColordown=colors.red
bcount=bcount+1
form1.button2.Text= form1.button2.text + " try"+ str(bcount)
form1.button2.Refresh
Function = 0
End Function
''
''
Function Form1_Button1_MouseUp( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
form1.button1.BackColor=colors.blue
form1.button1.BackColorHot=colors.blue
Function = 0
End Function
Hi Paul,
Thanks for reply. I was aware of the backcolorhot property, but wondering why it is as it is, compared to the label functionality. I guess what happens, as software languages/whatever develops, stuff gets added, it becomes more complex. And a bit like the qwerty keyboard, it is what it is through historic reasons, not necessarily the 'best' reasons today. Anyway, thanks to today's 'codeproject' I found a link to my ideal language https://www.codeproject.com/News.aspx?ntag=19837497624856860&_z=2684255 (https://www.codeproject.com/News.aspx?ntag=19837497624856860&_z=2684255) looks simple, can't wait to give it a try. :)
:D That made me laugh this morning
button text refresh OK in vers 1.7.7, but text does not scroll/multiline I think a few releases ago, you said you were removing properties/events that you had not yet implemented. I've just noticed that for label, mouse down/up works for both left and right mouse buttons and thumbwheel, whereas for button only for left mouse button. (I guess you'll be adding button events for mouse right and thumbwheel. This could run into fifteen pages of just button mouse events...)
To differeniate the mouse buttons, you can check the EventArgs variable "e"
Function Form1_Button1_MouseDown( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
form1.button1.BackColordown=colors.red
bcount=bcount+1
form1.button2.Text= form1.button2.text + " try"+ str(bcount)
if e.RButton then
? "Right mouse click"
end if
Function = 0
End Function
Buttons will not have multiline because the styles will not allow them without screwing up existing alignments.
Hi Paul,
I'm looking at this from the point of view of a newcomer to this visual programming of basic, as opposed to someone steeped in the intricacies of historic basic programming. From that point of view, I'm looking for consistency within the user interface. So, if on a property, only the left button of mouse can be easily used to create an event, then that should be the same for all properties where mouse clicks are allowed i.e. any mouse button within the label has an effect, whereas only the left within a button. I've not tested other properties for this consistency. But then, that's maybe just me going off on one. Of course, this could be completely avoided, if a label was treated purely as a label, i.e. an area for only displaying text, and mouse clicking whatever creates no events in that property, in the same way as key presses have no events.
Generally, except for form size problems, a single line of text on buttons is sufficient. However, for touch screen, square buttons are better than oblong, in which case two or more lines of text would be useful, hence my queries re scrolling. I suppose I should be suggesting round buttons for touch screens :-[
I'm pretty certain, that whatever I want to do, with help from here, I can get it done, but the boundary between easy and hard is not necessarily where I want it to be - such is life.
Best wishes,
Ray
Well, if somebody isn't willing to learn, it must not choose to work with a low-level compiler and the Windows API. There are languages such the VB.NET and C# that can use all the classes provided by the .NET framework and there is plenty of code available in the web to copy.
BTW using two lines of text with CXpButton is as easy as using carriage returns in the button text to break the lines
<button>.Text = "&Classic Button" & CHR(13) & "second line"
and set the TextFormat property to
<button>.TextFormat = DT_WORDBREAK OR DT_CENTER
@raymw
I don't understand your complaint about events related to labels, you intercept/use only the events that you want.
Quote from: Johan Klassen on August 28, 2018, 10:30:41 AM
@raymw
I don't understand your complaint about events related to labels, you intercept/use only the events that you want.
I'm not complaining, more likely making an observation. The boundary between a label and button is fuzzy, and where will the fuzziness stop? Why not have key presses in labels, and multi-line text in buttons, then you can add in more similar behavior, and all that will be different will be the name?
QuoteWell, if somebody isn't willing to learn, it must not choose to work with a low-level compiler and the Windows API.
Hi Jose, I thought the idea of the visual designer was to isolate the user from much of the windows api stuff. I can do most of what I
need want to do. It's just there appears to be a few boundaries which to me are in odd places. It is no big deal for me, just trying to make suggestions, test stuff, try and break it, whatever. I am very grateful to you and Paul for what you are both doing, although I must admit that I have little idea of how and, in some ways, why you do it.
Best wishes,
Ray
If you used standard buttons you will quickly notice the difference between a button and a label, both in aspect and behavior. Now, there are some users that have the caprice of using colored buttons. For doing that, visual styles need to be disabled and the button to be drawn using GDI, and they end looking like a label. There are still some differences like a label can't gain the focus. Paul knows that I was very reluctant to make the changes needed to work with different background and foreground colors because I find these buttons shabby.
Hi Jose,
Thanks for your explanation wrt button/label colours. I sort of agree, that there should be a clear distinction. However, much of windows 10 uses coloured buttons (can be readily emulated using Paul's labels), and as I often sort of simulate machine tools which often have colored buttons -e.g. red for emergency stop. However, I've seen some really garish examples, particularly in web pages. Thinking of which, why not have html5 (maybe have to be a subset) to freebasic as the gui? ( I can almost hear you screaming :o)
Best wishes,
Ray
> Thinking of which, why not have html5 (maybe have to be a subset) to freebasic as the gui?
"Ignorance is bliss". The Windows API doesn't speak HTML, only the Internet Browsers do. If you want to write a GUI using HTML, use a browser.
In fact, HTML buttons can be used by hosting the WebBroser control. I have done it. But to implement it into the Visual Designer won't be easy. If Paul gets bored... :)
We have to work on stopping Paul from getting bored, or distracted. I think I'd better keep quiet about buttons. Anything more exciting?
Lol :)
Writing a visual designer is a hell of a lot of work. Even after having writing Firefly Visual Designer and knowing somewhat about what needs to be written, it still takes a lot of time. I've been slower writing this visual designer because I want to try to do it better (right) this time. I also want to try to build it so that changes and updates later will be easier rather than hard coding a lot of stuff.
Visual designer vs. hand coding and learning API, etc - all of us have long debated this question. In a perfect world, we would all know the api inside and out but everyone learns differently. I have seen that over the years of having Firefly Visual Designer, that customers get more excited about programming because they can get things up and running faster. The mundane creation and positioning of forms and controls and the easy reactions to dealing with events/messages is taken care of. This allows the more curious programmer to branch out and ask different questions such as dealing with owner draw, or databases, or networking - all because they don't have to deal with the foundation visual stuff. Being 100% dependant on a visual designer is obviously not good either and will be detrimental to your skills in the long run. If a visual designer can help inspire you to start to take baby steps to begin coding an application then I've done my job. That desire will morph into further curiosities that will eventually see you creating and sharing code. It all takes time and desire to learn. Some possess those skills better than others. Always ask questions and be willing to read and learn. Simply copying code will only take you so far. Programming is not a talent learned over night but I have met many programmers here and over on the PB forums who started off slow but with a bit of encouragement and pointing in the right direction, turned out to be amazingly self sufficient and ended up putting huge smiles on my face with the code and programs they shared. I'd name names, but I run the risk of forgetting people or inadvertently giving public attention when they'd prefer not to. I remember downloading the POFFS database that contained all of the PB forum posts. I literally spend days and days reading posts and seeing how topics were dealt with. I marvelled at the genius of programmers who just seemed to "know it". I absorbed concepts albeit at a slow pace but I never stopped learning or giving up. I learned algorithms that helped with my understanding of programming logic. I built Cheetah Database that taught me about file structures and indexing (B+Trees). I look back on my code from 10 years ago and laugh at its ugliness... but the code worked. Ten years from now I will look back on the WinFBE code and laugh at its ugliness. At least I hope that I will because that will mean that my programming skills have gotten better.
I was once a Visual Basic programmer who relied on a visual designer and the safe comfortable ecosystem of Visual Basic. Luckily for me though, my DOS programming background helped me keep my inquisitive nature and desire to learn so I didn't get held back by the finite limitations of Visual Basic. I am not a programmer by trade, but the skills I've learned from programming has helped me immensely in my day job and life in general.
Wait, what was the question? I think I went off topic a bit. :)
IMHO RAD tools should be used to save work with repetitive tasks, not a as a way to avoid learning. So many millions of VB6 users, and most of them know less about the inner workings of it than I, that never have used it! You can easily recognize an ex-VBer by the way they write keywords: they are the only ones that like to use mixed case :)
I once advised to some friends of mine to no hire anybody as a programmer if the candidate was unable to write a simple GUI by hand.
We were talking about HTML buttons. I know how to do it, but as it often happens with my code, nobody will use it if it is not conveniently buried and they have to code it by hand instead of filling properties. Anyway, I will made some tests just for fun, but it won't be practical for building a GUI with many buttons, because it will waste too many resources.
Quote from: José Roca on August 28, 2018, 04:58:04 PM
You can easily recognize an ex-VBer by the way they write keywords: they are the only ones that like to use mixed case :)
I'm guilty of that :)
The next wave of programmers will be the JavaScript guys with their camal case.
firstName
lastName
fullName
too much to think about... I remember when we never had vdu's, and programmers had to wear hobnailed boots and hard-wire their own programs, accuracy required longer slide rules, and bison roamed freely through the streets of London. And then Clive Sinclair invented the pocket calculator, electronic watch, and the BBC stupidly chose the wrong microprocessor for their computer. I read an article in Byte, by the guys who developed the bios for the ibm pc. They had the first colour monitor. iirc they said it was black, green and then blue and white smoke. It's been downhill ever since.The ibm pc put it back by about 4 years, but all the companies were waiting for it, because you never got sacked if you bought ibm (but later you did, if you bought their luggable!)
fwiw, I can usually recognise programs that have been written in Borland turbo pascal - they handle numeric data entry differently cf what I perceive as the Microsoft standard. - and as a user I find it a tad annoying.
I still rarely use tabs for text layout. When I used coding forms/punched cards, it was easier/usual to use spaces. Made a difference when the glass teletype came out, and you had to do your own typing, but by then I was out of full time programming, and had a couple of others to do the grafting. There's probably a book in there somewhere.