|
Post by Rod on Jul 25, 2020 11:09:27 GMT -5
I rest my case, Gordon, eliminating the borders gives you fully 800 pixels numbered 0 to 799. Pixel 800 does not exist and will be off screen/clipped. Box 799 599 should show.
|
|
|
Post by Brandon Parker on Jul 25, 2020 14:25:26 GMT -5
Carl, As long as there is an easy way to get the "drawable" width & height from the control and the drawing commands start at (0, 0) (as the first visible pixel) then I would say having the control with a border taking up some of the specified width & height should be fine.
I mean, when one creates the control one is specifying its size as depicted on the window. This is understood by everyone I'm pretty sure, but the problem with LB 4 (and previous) is that when there is a border drawn the drawing commands are not taking this into account. This causes problems for people that are not aware of what is going on.
That is my take on it ...
{:0)
Brandon Parker
|
|
|
Post by neuropsychddx on Sept 15, 2021 12:09:39 GMT -5
Dear Carl,
After having learnt BASIC in school about 20 years ago. I have found interest in programming again in Liberty BASIC. I will share my experience of using it and maybe some suggestions for LB5. The tutorials are easy to understand and got me up to speed with the logic quickly. Freeform is great, though it looks archaic. The GUI portion of the tutorials need to be updated, as finally people want to program GUI software for their day-to-day use and not solve simple problems. The tutorials need to provide solid examples of making real world database application, which is what I think the average LB uses would like to develop. I tried to program a notepad app from the ground up using liberty basic. After the basics, you are immediately confronted with win32 api if you want to do anything real world, which most users will have no idea about.
For example, unlike IUP gui library, liberty basic edit box does not provide inherent commands to find out line number and column numbers. There is no way to trap key events in window without using win32. Scan function does not help much. Foreground colors on the text is global and can be declared only once. I could not find any LB modules or ways to develop LB modules from which functions can be called like LB commands, without use of calldll function. For example, scriptbasic and freebasic allow #include function and can be used to include IUP or FLTK GUI libraries. FLTK though not good-looking is easy. The appeal for LB can be enhanced if
Programming should be fun, not painful. I hope that in LB5 some of the above are included.
|
|
|
Post by Walt Decker on Sept 15, 2021 16:58:33 GMT -5
I think that is a mistake. What if one wants a multi-select and/or sorted list box, add a ws_ex_ style to a control, create a multi-line edit control that functions the way a multi-line edit control is meant to function?
|
|
|
Post by Carl Gundel on Sept 15, 2021 17:45:32 GMT -5
I think that is a mistake. What if one wants a multi-select and/or sorted list box, add a ws_ex_ style to a control, create a multi-line edit control that functions the way a multi-line edit control is meant to function? Stylebits will be deprecated. Specifying things like multiselect, or multi-line, etc. will be done using cross platform functions.
|
|
|
Post by Chris Iverson on Sept 15, 2021 18:17:49 GMT -5
I think that is a mistake. What if one wants a multi-select and/or sorted list box, add a ws_ex_ style to a control, create a multi-line edit control that functions the way a multi-line edit control is meant to function? As Carl said, the reason STYLEBITS are being deprecated is because LB5 is a cross-platform product, whereas STYLEBITS are explicitly Windows-only. Replacing it with custom widgets that are both fully customizable AND compatible with each platform (as well as behaving the same on each platform) is a far better solution in the long run. That doesn't mean you won't be able to use it; you'll still be able to interface with the Windows API, but if you do so, you ensure your program won't work on other platforms.
|
|
|
Post by Carl Gundel on Sept 16, 2021 7:27:10 GMT -5
I think that is a mistake. What if one wants a multi-select and/or sorted list box, add a ws_ex_ style to a control, create a multi-line edit control that functions the way a multi-line edit control is meant to function? As Carl said, the reason STYLEBITS are being deprecated is because LB5 is a cross-platform product, whereas STYLEBITS are explicitly Windows-only. Replacing it with custom widgets that are both fully customizable AND compatible with each platform (as well as behaving the same on each platform) is a far better solution in the long run. That doesn't mean you won't be able to use it; you'll still be able to interface with the Windows API, but if you do so, you ensure your program won't work on other platforms. I can simulate the effect of stylebits on the cross platform widgets, and that would make the 'new' stylebits cross platform. However there isn't going to be perfect 1:1 functionality between the native Windows widgets and the new cross platform widgets. On the whole you will have more functionality with less bit fidgeting. If you absolutely still need LB4 compatibility you will still be able to use LB4.
|
|
|
Post by Walt Decker on Sept 16, 2021 9:52:01 GMT -5
To me it makes little difference. I probably will not be a mobile entity on this rock in a few years.
Making controls completely customizable is an admirable endever. I doubt it can be done. In the case of windoz, can you accomadate BS_OWNERDRAW, SS_OWNERDRAW, etc?
|
|
|
Post by White on Oct 19, 2021 9:49:22 GMT -5
I would like to be able to call third-party .bas or .tkn files from the program. That is, we need something like include, load or import
|
|
|
Post by White on Oct 19, 2021 10:01:04 GMT -5
I decided to rephrase. We need to be able to import our own constants and functions from .bas or .tkn files.
|
|
|
Post by Carl Gundel on Oct 19, 2021 12:48:58 GMT -5
I decided to rephrase. We need to be able to import our own constants and functions from .bas or .tkn files. You can use the LIBRARY statement in LB5 to use code in other files in your programs. Of course LB5 is still in alpha test, but for some people it is suitable for casual programming. What sort of development projects are you working on? -Carl
|
|
|
Post by alincon on Oct 19, 2021 14:06:57 GMT -5
LB4 has an undocumented feature that allows branching to two different places by clicking on a listbox item once or twice
listbox #appt.lbMon, mon$(, apptDel, 5,50,190,325 ... #appt.lbMon,"SingleClickSelect patientCall"
Will this feature also be in LB5?
r.m.
|
|
|
Post by Carl Gundel on Oct 19, 2021 16:56:26 GMT -5
LB4 has an undocumented feature that allows branching to two different places by clicking on a listbox item once or twice listbox #appt.lbMon, mon$(, apptDel, 5,50,190,325 ... #appt.lbMon,"SingleClickSelect patientCall"
Will this feature also be in LB5? r.m. It is in LB5 and is not undocumented. From the help file:
|
|
|
Post by alincon on Oct 19, 2021 18:51:21 GMT -5
But in my program example double-clicking goes to the apptDel subroutine, and single-clicking goes to the patientCall subroutine. That's what is undocumented. Quite a few LBers were surprised when I brought it up a while back.
r.m.
|
|
|
Post by alincon on Nov 1, 2021 10:16:09 GMT -5
In LB4 list boxes are based on a one-dimension array. In LB5 I would like to be able to base a list box on one dimension of a multi-dimension array. So if I read in a random file and built a two-dimension array from the fields in the records and the first dimension was name, then I could base a listbox on that and call up the records by name.
r.m.
|
|