PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: text box problem, maybe  (Read 203 times)

raymw

  • Senior Member
  • ***
  • Posts: 284
text box problem, maybe
« on: September 13, 2019, 10:25:31 AM »

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.
Logged

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8848
  • Windows 10
    • PlanetSquires Software
Re: text box problem, maybe
« Reply #1 on: September 13, 2019, 11:15:43 AM »

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?
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #2 on: September 13, 2019, 02:14:59 PM »

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. 
Logged

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #3 on: September 13, 2019, 03:26:19 PM »

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
Code: [Select]
''  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.
Logged

SeaVipe

  • Junior Member
  • **
  • Posts: 175
  • Windows 10 Ubuntu 18
Re: text box problem, maybe (1.9.2)
« Reply #4 on: September 13, 2019, 04:03:07 PM »

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.
Logged
Clive Richey
There is nothing government can give you that it hasn't already taken from you in the first place. Winston Churchill

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8848
  • Windows 10
    • PlanetSquires Software
Re: text box problem, maybe
« Reply #5 on: September 13, 2019, 04:50:43 PM »

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.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #6 on: September 13, 2019, 05:59:11 PM »

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.
Logged

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #7 on: September 15, 2019, 09:52:51 AM »

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.
« Last Edit: September 15, 2019, 10:12:07 AM by raymw »
Logged

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8848
  • Windows 10
    • PlanetSquires Software
Re: text box problem, maybe
« Reply #8 on: September 15, 2019, 11:58:53 AM »

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.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #9 on: September 15, 2019, 12:20:37 PM »

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.
« Last Edit: September 15, 2019, 12:24:18 PM by raymw »
Logged

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 8848
  • Windows 10
    • PlanetSquires Software
Re: text box problem, maybe
« Reply #10 on: September 15, 2019, 01:31:08 PM »

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.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

raymw

  • Senior Member
  • ***
  • Posts: 284
Re: text box problem, maybe
« Reply #11 on: September 15, 2019, 02:30:28 PM »

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.
Logged