Hi, It's been a while since i was on here, and recently - today - I have started to write a simple program to interface to arduinos. It surprised, even me, how much I'd forgotten about fb. Anyway, I find that when the command window opens, I get a dozen or so lines showing 'dwExStyle: 512'. I can't remember that happening previously. I'm using winFBE 1.9.1 (32 bit). When I arranged the text boxes, etc. in the graphics designer, some of the boxes seemed to disappear off the edge of the window (jerky mouse movements) and I'm not sure if I've found them all.
Hi Ray, turn off the "Snap lines" feature (found under the Designer menu). That will fix the jerky mouse movement thing. It is, let's say "a work in progress". :)
You can also try downloading the 1.9.2 beta that is on GitHub
https://github.com/PaulSquires/WinFBE/releases
That beta made a LOT of changes to the visual designer so you probably won't have as many issues. I strongly encourage you to try that version. Here is the direct link to the download: https://github.com/PaulSquires/WinFBE/releases/download/1.9.2-beta1/WinFBE_Suite.rar
That dwExStyle message may be a leftover debug output message that I was using for some code. I think that was removed.
Thanks Paul, seems to be OK now. Not sure if in your plans, but I think it would be useful if a text box and a label could be combined in the same object - it would allow quick form layout, and save on my coding.
I seem to have no problem with gui, and your debug hangovers have gone, but still jerky movement unless as you mentioned I switch off the auto align. If the buttons/textboxes, whatever whiz off to the right or bottom of the form, then a resize of the form brings them back into view, and they can be deleted or moved. What happens when the go off the form to the top or left? I can't stretch the form edges in that direction, are they actually deleted, or still in the system with negative axes?
Anyway, I could do with some code snippets. I have a button to start the reading via serial port of the various sensors connected wirelessly to the master arduino. It is a function, started off by a button click when various settings have been configured consisting of the opening of the port, and then a 'loop' which reads the serial stream. I can't remember how to interrupt that loop by the press of another button on the gui. The only way I can stop the loop is by closing down the command window, (I have debug values printing to the command window) the form does not respond and greys out after two button presses.
Thanks, Best wishes,
Ray
Maybe have a "Stop" button and when clicked sets a global boolean gStopReading to True.
Add a call to AfxDoEvents within your loop and then check the value of the global gStopReading variable right after the AfxDoEvents. Exit the loop if True.
Maybe that works?
Thanks Paul, seems to do the job.
Hi Paul,
I'm printing my debug to console. If I compile program, I get no error messages or warnings, except if I compile win32 GUI (Release). I think it is caused by something not matching in the compile options on the edit screen and the build configurations under the Options tab. I thought they would be linked together. The error is in a function I have for handling strings, maybe the different compiles do not include 'string.bi' i.e the release ignores #include "string.bi"
Best wishes,
Ray
Hi Ray - I don`t understand your question.
You`re developing and writing output to the console (using PRINT statements I assume) using Win32 Console (Release)?
When you switch to Win32 GUI (Release) you are getting errors during the compile process?
WinFBE does not automatically add or remove the #include "string.bi" file. I assume you're including that file in order to have access to the FORMAT function.
ok, in editor on the 'line to the right of where you can hit the arrow keys for compile, etc'. there is a drop down list for compile options. Select any of that list - then open on the top line Options- build configuration and you see the same compile option is selected. but, if you change the compile option there,in the build configuration page it does not show the change in the editor page - the box by the compile buttons.
I could not compile as gui, no console, but could with other compile options. Also, the program I'm writing does not close properly from the gui window 'X' . i. e. it disappears, but can't then recompile - says it is still running. I don't recollect having to do anything else to shut down my written programs.
Best wishes,
Ray
ps a few keywords are not highlighted in winfbe, 'frac', for example, but 'fix' is.
Quote from: raymw on August 09, 2019, 04:14:31 PM
ok, in editor on the 'line to the right of where you can hit the arrow keys for compile, etc'. there is a drop down list for compile options. Select any of that list - then open on the top line Options- build configuration and you see the same compile option is selected. but, if you change the compile option there,in the build configuration page it does not show the change in the editor page - the box by the compile buttons.
Thanks - I have fixed that. I made a silly error there.
QuoteAlso, the program I'm writing does not close properly from the gui window 'X' . i. e. it disappears, but can't then recompile - says it is still running. I don't recollect having to do anything else to shut down my written programs.
Sounds like there is a running loop or thread within your program that hasn't terminated leaving the program in memory. If you still have the problem then I can take a look at your program for you if you wish.
Quoteps a few keywords are not highlighted in winfbe, 'frac', for example, but 'fix' is.
Thanks - I have added FRAC to the syntax highlighting.
Quote from: Paul Squires on August 07, 2019, 10:38:30 AM
Hi Ray, turn off the "Snap lines" feature (found under the Designer menu). That will fix the jerky mouse movement thing. It is, let's say "a work in progress". :)
Looks like I found the source of that snap lines jerky mouse movement. I was not resetting the snap lines properties once the mouse button was released. This caused problems when subsequent moves of the control took place.
Great, I knew you would fix it, thanks.
still problem with compile
target: win32, 486, 32bit
compiling: C:\Users\Ray\Desktop\rayprojects\ray_sensors\anilserr.bas -o C:\Users\Ray\Desktop\rayprojects\ray_sensors\anilserr.asm (main module)
C:\Users\Ray\Desktop\rayprojects\ray_sensors\anilserr.bas(269) error 99: No matching overloaded function, ACCEPTSRETURN()
error 99, (line -19) I had it compiling and running OK. I loaded in another previously running basic file, to remind me of some code I'd written in there. When I saw what I wanted to see, I deleted the added program, and then when I went to run the original, it gave the error message. Both programs have the gui forms. Not sure if you can replicate this.
There was not a very complicated form, so I copied the basic file and loaded into wfbe editor. All of your form design was commented out, as usual, but the error is here,
function readerType.FormInitializeComponent( byval pForm as readerType ptr ) as LRESULT
dim as long nClientOffset
pForm->Text = "Reader"
pForm->SetBounds(10,10,500,300)
pForm->Button1.Parent = pForm
pForm->Button1.Text = "Read File"
pForm->Button1.SetBounds(295,62-nClientOffset,114,32)
pForm->Button1.OnClick = @reader_Button1_Click
pForm->Text1.Parent = pForm
' pForm->Text1.AcceptsReturn =
pForm->Text1.Text = "temperature1a.txt"
pForm->Text1.SetBounds(60,62-nClientOffset,187,35)
pForm->Label1.Parent = pForm
pForm->Label1.Text = "File Name"
pForm->Label1.SetBounds(61,26-nClientOffset,155,24)
pForm->Controls.Add(ControlType.Button, @(pForm->Button1))
pForm->Controls.Add(ControlType.TextBox, @(pForm->Text1))
pForm->Controls.Add(ControlType.Label, @(pForm->Label1))
Application.Forms.Add(ControlType.Form, pForm)
function = 0
end function
I commented out the line in error, as you can see, and it is now back running. Maybe there is a clue in here somewhere, as to why is is so easy for me to break this.
A few days ago I fixed a bug where Form files would not load correctly into an existing project via the "Add files to project" menu option. I expect that this may have something to do with it and why the value for the AcceptsReturn property got blanked.
I am close to having the code generation for the StatusBar and ToolBar finished. When that is complete then I will upload a new WinFBE package for everyone to test.
Anyway, now got back to where it was. Made a new project, designed the form (only needed a textbox and window) saved it and ran. Then pasted in the text from previous file, amended the few references to button and text to the new names on form, and back working again. But, it would be good if this didn't happen so frquently, and recovery more difficult with a complicated form. It may be useful to be able to generate a form from the commented code of the basic file.
cross posted, there, Paul. I'll probably find out if you've fixed it ::)
I've got it fixed now, date conversion, removal of jitter etc. Just need to decide on drawing pictures. In the meantime, I've gone retro, back 50 years or so when i was programming an IBM 1130 in fortran g (or h) or was it e/f? Anyway, there was 16k of core memory, and a £40,000 chain line printer (no fancy lower case back then, no 'glass teletypes'), so we'd print graphs/diagrams in ascii art on the stripey green paper.
Here's part of the temperature data from the console.
This has all been running well for a few weeks now, I leave the data collection program running 24/7. The program and its windows only showing in the task bar. However, I want it to send a pop up message box window on rare occasions e.g. when any of the batteries need changing. I can't find anything in fbe , fbx or api help referencing pop up messages, and can't find the examples/tutorials, I'm sure it exists however.
I think it was the 'forth' programming language, consisted of a line of symbols that could replace pages of fortran or cobol. The problem being, the next day, you couldn't understand what or how you wrote it. I'm feeling the same now about any program I've written, in any language.
Edit to add - I found an answer in the CWindows class (the help search does not cover all the topics, you have to be in the correct section.) I'm always looking for a simple answer...
I don't think the standard VB message box will behave in the manner I want it to, in fact I don't think individual message boxes is the best solution for me. I think it would be better to popup a form, with a list of the errors in a text box therein. Once acted on I can close down the single form, instead of individually clicking buttons on individual message boxes. Also, in my experiments, it seems that the main program does not continue running unless the message box is closed/acted upon by the user, but I may not have found all the options.
Anyway, my idea is that the main program, (which is running in the task bar, reading from usb port every ten seconds, and writing to hdd,) when it finds an error value which is significant, e.g. flat battery in one of the transmitters, then I'd like it to open a popup form with the error in a text box in the middle of the screen, and subsequent errors are written to that text box. However, in the brief trial I have made, with one form generating a counter that is displayed in the text box of the popup message form, if either of the forms are moved, then the counter stops, and the forms become unresponsive.
'' Remove the following Application.Run code if it used elsewhere in your application.
Application.Run(Form1)
#include once"pup.bas"
function showpup() as String
dim k as Integer
for k=1 to 1000
form2.text1.text=str(k )
sleep 2000
next
return ""
end function
Function Form1_Button1_Click( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
showpup()
Function = 0
End Function
(form2 is the form with text box in pup.bas)
(edit to say, this thread may be better in another section, I don't think it is solely a winfbe feature.)
Ray, can the counter run in a different thread?
It could, but this was only to test if a program could run in the background, and send messages to a form on the desktop. I know nothing about running different threads.
added what I think is a separate thread. Makes little difference.
'' Remove the following Application.Run code if it used elsewhere in your application.
Application.Run(Form1)
#include once"pup.bas"
sub showpup(param as any ptr)
dim k as Integer
form2.show
for k=1 to 1000
form2.text1.text=str(k )
sleep 2000
next
end sub
Function Form1_Button1_Click( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
Dim As Any Ptr thread = ThreadCreate(@showpup, 0)
for k as integer =1 to 50
form1.button1.Text = str(k)
sleep(1000)
next
threadwait(thread)
Function = 0
End Function
Any attempt to move eithr form, causes it to fail (not responding) once button1 is clicked.
In loops with sleep, I have found that application.DoEvents at the top of the loop solves "most" of my locking up issues.
Thanks, I forget that more than I remember. I don't think I'll need the threading for this application. But, I've learnt something, but generally these days, 'it's in one ear, and gone tomorrow'
Hi Clive,
latest test below, getting to what i want wrt test. Pup.bas is the code for form2, it only has a textbox on it that is used
'' Remove the following Application.Run code if it used elsewhere in your application.
Application.Run(Form1)
#include once"pup.bas"
''
''
Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
' do some stuff to give time to put form1 on taskbar
dim k as integer
for k =1 to 5
form1.button1.Text = str(k)
application.doevents
Sleep 1000
next
' open message form2
form2.left =250
form2.top =150
form2.show
'do some stuff on form2 and form1
for k=1 to 20
form2.text1.text= form2.text1.text+"Message Number "+ str(k) + chr(13)+chr(10)
'' do something on form2
form1.button1.Text = str(k) +" something"
application.doevents
sleep 1000
Next
Function = 0
End Function
''
''
Function Form1_Button1_Click( ByRef sender As wfxButton, ByRef e As EventArgs ) As LRESULT
' nothing to see here...
Function = 0
End Function
So, I run form1, and after five seconds it shows form2 and updates the textbox in form2, and carries on doing it's own thing. So far, so good. The major problem, is moving form1 down to task bar, before the initial 5 seconds is up, then form2 doesn't show on the screen (the loops keep running, however). I want form2 to appear, and stay as the top window, until I close it. It needs to appear, in fact whenever text is sent to its text box. The other problem, most likely threads will help that, is moving a form e.g. mouse over title bar, and mouse button down, then the program pauses, lops stop counting, whatever. I've tried the various window types, etc, in the form2 designer gui, but they do not seems to add anything along the lines that i need. Hopefully there is another magic couplet, like application.doevents, that'll get it working.
For this type of application you definitely need to use a worker thread because the mouse moves will interrupt the UI thread. Check out my code below that will allow you to move Form2 while not blocking the the printing of the text to your textbox. Also, notice that I removed a DoEvents and also added Form1 as the parent to your Form2.show( Form1) call.
#include once "pup.bas"
dim shared As Any Ptr gThread
' Remove the following Application.Run code if it used elsewhere in your application.
Application.Run(Form1)
Sub WorkerThread( ByVal userdata As Any Ptr )
'do some stuff on Form2 and form1
for k as long = 1 to 20
Form2.text1.text = Form2.text1.text + "Message Number "+ str(k) + chr(13)+chr(10)
'' do something on Form2
form1.button1.Text = str(k) +" something"
sleep 1000
Next
End Sub
''
''
Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
' do some stuff to give time to put form1 on taskbar
for k as long = 1 to 5
form1.button1.Text = str(k)
application.doevents
Sleep 1000
next
' open message Form2
Form2.left = 250
Form2.top = 150
Form2.show( Form1 )
' Launch another thread
gThread = ThreadCreate( @WorkerThread )
Function = 0
End Function
''
''
Function Form1_FormClosed( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
ThreadWait( gThread )
Function = 0
End Function
Hi Paul, I had Ray's code working with DoEvents but yours is much more elegant plus it works properly!
Moving the forms was causing a slight hesitation in the counter which I'm assuming is caused by the mouse movements interrupting the UI thread you mentioned in your post.
Thanks, I'll try it out. I'd got to the stage, moving things around into different threads, that it would work with care. A note for Paul playing with the gui, It appeared that the borderr styles for forms apearred listed under borders for text boxes. I got an error message that the borderstyle did not exist. Not sure that I can repeat.
I think it comes up with fixed 3d
Hi Paul, I need it to run when the main program is in the task bar. The main program runs 24/7, monitoring temperatures every ten seconds, and saving changes to hdd. Occasionally, a battery will go flat, or other error occur, perhaps three times a week, or so, the main program can detect that, and I want that to pop up a message box. The message box needs to be annoyingly on top of whatever else may be on the screen (think w10 update style...) What I am trying here is just a simulation, I don't want to mess with the main program, until I know it will be worth while making a change. Sometimes, there can be a stream of error messages at a rate of one every ten seconds, that is why an ordinary pop up won't do, too much clicking to close down.
My most recent simulation almost worked, except moving the message form stopped everything while it was being moved. I tried adding another thread, but couldn't get it to compile.