Hi, I've been trying to add lines to a text box. If I programmatically send chr(10)chr(13) or 13,10, it does not take a new line. However, I can enter returns via the keyboard as a user - hope that makes sense. I've fiddled with the various textbox settings, accepts return, etc., but I am not able to get newlines accepted by the textbox. I would use a listbox, since it is basically a list of strings that I'm generating, but the user can not easily edit list box items, without me writing a bit more code, the text box would be fine, if I knew what characters to send to get it to show new lines. (previously I was showing the data fine on the console, I was hoping to be able to simple do a prtext (instead of print) sort of command, to print to textbox. version 1.9.2, not a beta.
The example program that I posted for you a while back worked okay by adding lines to the textbox (see attached).
Is it that once the text is added that you then need that text scrolled into view?
Thanks for the prompt reply. That is what I'm doing, adding cr/lf to text and adding new text, as in the example you sent. BUT - on digging into why it does not work (your example is OK) on this form. I noticed in the tool settings an anomaly. I think that something screwed up, earlier on in my gui. If you look carefully, you can see that Character casing is different, one is saying 'casing.', the other 'case.' I deleted the text box, and created another, this showed casing, which I think is correct, but it still would not accept cr/lf (it would not take a new line). Unless there is some other setting that I'm missing, then I think I'll start with a new gui. Come to think of it, this form had a few lost checkboxes, off the screen, due to the snaplines, I found them by expanding the form, and deleted them., so maybe that was related. I guess you have a tool which has an option of CharacterCase.Normal, which seems to have been linked to this text box.
I sort of start doubting my sanity, couldn't even get a simple textbox on a form to be updated based on code I knew worked '' Remove the following Application.Run code if it used elsewhere in your application.
Application.Run(Form1)
Sub WorkerThread( )
'do some stuff on Form2 and form1
for k as long = 1 to 20
Form1.text1.text = Form1.text1.text + "Message Number "+ str(k) + chr(13)+chr(10)
Next
End Sub
Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
form1.text1.Text = "line 1" +chr(13)+chr(10)
form1.text1.Text = form1.text1.text +"line 2"
workerthread()
Function = 0
End Function
same thing all on one line. I've gone back to 1.9.1, and that is OK. I'll try reinstalling 1.9.2, and see if that is OK now. But, to get that to work, had to cut and paste my code, It failed if I simply loaded the basic file.
In the screenshot of Ray's code (downloaded earlier) Casing. is the default but all 3 choices in the pulldown are Case.. Both run correctly, restarting WinFBE shows Case. was saved from the previous compile and run.
Thanks guys, that is an error in WinFBE when it assigns the default property for CharacterCasing. It should be assigning "CharacterCase.Normal" but it was assigning "CharacterCasing.Normal" incorrectly. I will include the fix in the next update.
Anyway, I've got it going now. had to go back to an earlier iteration of my code, since, I think that I was modifying code which had errors created by an earlier gui, which i guess I managed to corrupt.
Hi, I reinstalled 1.9.2. However, It has now been corrupted again. I'm not at all sure what is happening, but it appears that if I load and do minor edits on a previous working code, it behaves itself, but if I create a new project, then that does not handle chr(13), chr(10) plus other stuff I expect. There are numerous error messages referring to duplicate definitions, as if the gui has been added in twice, or something, in the program i am working on. I have backups on the server, so I can recover, but in the meantime I'm going to poke around, see if i can find exactly how much is duplicated, and why. The last thing I did, before I noticed this happen, is that I opened the program to modify it, absentmindedly clicked a number of times on a button in the designer window (thinking it was the actual gui for the running program), and then after that, it would not compile, and for subsequent different new programs, it came up with the cr/lf problem. It is almost that two or more instances of the code has somehow been generated. I can sort of understand that the original program would not compile, but I do not understand why the boundary has been crossed that it does not correctly compile new programs, it as if it has broken wfe itself.
edit to add, here's a screen shot of the relative areas of part of the problem, not sure why it has duplicated the functions.
Can you attach the boxerfinal.bas file to your post so I can look at it?
I remember in the past that you were manually editing your form files outside of WinFBE using an external editor and then re-adding that file to the project either through opening it within WinFBE or copy/pasting into the editor. Are you still doing that? Just curious becuase I expect such a practice could lead to duplication.
no, not editing this outside. Every time i compiled the file, the duplicates increased. I'll see if I can attach one. I've gone back to 1.9.1 again, and downloaded yesterdays version, which overwrote the faulty version, but luckily the last faulted version was still in notepad++, so hopefully its useful, I've attached below. ignore my comments wrt common subroutines, it is still all one file, but I wanted to extract the bits I tend to use a lot - still obviously under development. I've got back tp a working version.
Interesting. The file does indeed have multiple controls. Looks like a lot of them have negative location values. Most likely the result of the SnapLines problem that was present a version or so back. Not sure how to fix that file other than to manually delete all the controls with the negative values.
Once this has happened, then it seems that any other gui program I write creates a similar result, it is almost as if the editor is being over written. If no one else is getting similar problems, then it may be something happening here, hardware, keyboard jammed, whatever, but I've not had other problems running software. Thanks for looking.
Not necessarily wanting to start another thread, only looking for a quick answer, for a change.
How do you specify the number of entries (size) of the listbox (wfxlistbox) as used in the designer, and what is the size limit?
Hi Ray,
Here is how I've been adding to a listbox in my WinFBE test project:
With FrmMain
.lstReasons.Item(0).text = "Daily"
.lstReasons.Item(1).text = "Debugging (Inc App Build #)"
.lstReasons.Item(2).text = "Power Outage Boot"
.lstReasons.Item(3).text = "Unknown"
.lstReasons.Item(4).text = "_"
' or
.lstReasons.Items.Add("Item 7", 7)
End With
I found this line in the Windows API help:
"Windows 95: The wParam parameter is limited to 16-bit values. This means list boxes cannot contain more than 32,767 items. Although the number of items is restricted, the total size in bytes of the items in a listbox is limited only by available memory."
Thanks, a bit of a restriction, but can most likely work around it. You get some interesting results if you read in a large file, line at a time, into listbox.
Ok, reading a file with about 2,200,000 (2.2 million) lines of code, a line at a time, parsing the g-code and plotting each line takes about 4 hours! (about 150 plots per second).
Last December,( iirc wrt the date), I wrote a far more complex program using firefly, that loaded the whole g-code file into memory (using the virtual list example) and as a side effect it could produce a reasonable drawing using the standard free basic line drawing commands, and that loads the same 2.2 million line g-code file, and creates the drawing in just a few seconds. However there is no method for varying brush widths, etc. I can either look at speeding up the winfbe version (it is actually drawing at a higher resolution than the screen can display) or add code to generate a line width for the firefly version.
Well, I dumped the cgi graphics, and went back to the simple graphics in free basic. I sort of wrote my own brush/line drawing routine (takes me back to the trs 80 days) and got the drawing time down to 1.75 minutes. I looked at a few variable values, and got to 1.25 minutes. I may try and tune it some more, but the law of diminishing returns will come into play. Most likely, I will put my line drawing code into the g-code editor that I wrote with firefly, since that is more useful, as I can see all the workpiece dimensions, etc. and I think that it may also complete a drawing slightly quicker, since it is not reading in a line from file, parsing, drawing, reading another line.
I've attached a larger file image, over three million lines, and it took 1.75 minutes to draw. To machine, it would take about 14hours.
Annoyingly,for this particular purpose, the basic graphics coordinate system is stuck by default in the old raster scanning display era, which is based on line printers, I guess.