Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Paul Squires]

I have a draft WinFBE 1.8.8 release posted on GitHub. If you are feeling adventurous and would like to download and try the suite then please do so. I would love to hear your feedback and especially any major bugs and/or annoyances. By far, the vast majority of changes relate to the code editor itself. The visual designer has not seen much love other than the initial addition of the Image Manager and a couple of image properties added to the Form and Button controls. When ready, this draft will be released as 1.9.0. Subsequent releases will then focus on the visual designer.

https://github.com/PaulSquires/WinFBE/releases

Good luck! (well, maybe I shouldn't wish "luck" because the draft is pretty stable - at least on my system).

[SeaVipe]

Hi Paul, the link to GitHub in your previous post is still showing 1.8.7. Tried "Latest release", but maybe I'm not looking in the right place or the site hasn't updated yet...

[Paul Squires]

Sorry, try again. This was my first time ever trying to post pre-release version. I guess the draft was only showing for me. I released the draft so it should there now.

[SeaVipe]

Okay, that worked, thanks.

[Joerg Buckel]

Hello Paul
I have three little things.

- The German translation is not completely displayed in IDC_FRMSNIPPETS_LABEL4. (frmSnippet.inc)
  If you change the value from 250 to 350, it fits.

So that you don't have to load and try the translation, I have already adapted the line for you. :-)

pWindow->AddControl("LABEL", , IDC_FRMSNIPPETS_LABEL4, "(" & L(90, "Press TAB in code editor to activate") & ")"", 376, 77, 350, 20, _

- I fixed two errors in the translation. The corrected file is attached.
- You split project files into Main, Resource, Header, Modules and Normal.
I'm not sure what the difference in content is between modules and normal for you.
Maybe I have to adjust the translation in this point again.

[Paul Squires]

Hi Joerg, thanks for the report, I have made the changes and added your updated language file.

The whole issue of "modules", "header", "resource", "main", "normal" will be a little odd for ex-PowerBasic programmers. It appears to be a common practice for FreeBasic programmers (much like C and C++ programmers) to compile individual files into standalone object files and then link all of those files to a main file. This provides the benefit of faster compile times because the source does not need to be recompiled if an object file exists and the code file has not been subsequently modified. The FB compiler source code is a good example. There is a 100 source code files that get compiled into individual object files and are then linked to the fbc.bas main file.

As I was rewriting WinFBE this past month, I started to separate the code into a better division of logical modules with separate header files. I found several instances where I had made errors using global variables and equates. I would not have found them if I had kept the program structure the way it was.

In WinFBE, a "module" would be one of those standalone .bas files that gets compiled into an object file. In a project, if you open a .bas file then it will automatically be added to the module section. You can move it to normal or main if needed. A "header" file would be a .bi file and should only contain Declares, Type, Defines, Const and Enum definitions. You #include these header files in module files that need to reference each other. A "normal" file is basically any file that does not have a file designation. In traditional PowerBasic style projects, you would have a "main" file and all of the other files would be designated as "normal" (all of the *.inc files). You would then #include those *.inc files in the main *.bas source file. WinFBE source code is currently set up like this. I am starting to move it to the module approach more so as a learning exercise and to conform more with the way that FreeBasic handles projects. Will it be better? Probably not, but for very large applications it does have a benefit of focusing the programmer to create small self-contained units of code.

[James Fuller]

Paul,
  With a tiny exe mentality it has been my experience to move away from obj modules in favor of source code only. Yes it takes a few seconds longer to compile but the reduction of the exe's size can be substantial.
In my case, working with c++, all the source needs to be in one file but that's how my translator works.
I believe Fb is just as good in not including dead source code .

James

[Paul Squires]

Hi James, I agree with you.

I need to be able to provide both methods because FB'ers would expect to have that choice.  :-)

Paul

[raymw]

Hi Paul,
I thought i would test it out. I have a requirement for a simple little random number generator program, just a couple of text boxes and a button for the gui. However, I was interrupted in the development cycle (lunch - OK, it's for wimps) and now when I reload the project, I get just the toolbox - no basic files. Clicking anywhere, crashes/closes win fbe. Seems to work OK with other recent projects. I've a feeling that you've added more modifications cf previous versions, and this will most likely produce more such errors. (I know 1.8.8 is draft 'cos you said so)
Fwiw, the attraction to me with the FBE editor, was the simplicity of the ide, the gui, etc. At the moment, I'm not so happy with what I perceive as the complexity creeping in, the display of the various additional files as shown in the explorer. I am also used to the concept of something being 'closed' as meaning it is saved and removed from the workspace (it's no longer needed, so closed) Of course, six of one, half dozen of the other.

Best wishes,

Ray

[Paul Squires]

Hi Ray, you might want to zip up that project and email it to so I can take a look to see if there is something in the program that is causing the loading problem. I am not sure what you mean by your "closed" comment. In a project, files are closed in the sense that they no longer display in the tab across the top of the editor. They always remain open in the project unless you explicitly issue a "Remove from project" request via the menu. If anything the amount of complexity is being reduced other than the visual regrouping of source code files which is pretty consistent with how other FB editors treat open files. The visual designer is a work in progress and I have been making a number of changes to it. Be wary of the Button control with images added to them because I have changed their behaviour. Not by much but a little bit. I almost have the PictureBox control ready to rollout now as well.

[raymw]

No problem with what I'm doing, but gave me a question or two. What is the limit for the number of lines you can have in a text box? I generate an array of numbers and copy them to a text box with a vertical scroll bar. I've noticed that if the list is more than about a 1000 values, that said text box flickers a lot, but in most cases it eventually stabilizes, and I can then access the list by means of the scroll bars. However, if I try to use the scroll bars before it stops flickering, a message pops up to the effect it is not responding. A list of 5000 items takes about 50 seconds for the text box to be usable, I gave up on 10,0000 items. It is not that obvious when the text box is complete, perhaps I need to add a bell, or whistle...

[raymw]

Sorry, Paul, bit of overlap in our posts. I've moved on from that original problem, not sure if I can find the project, may have deleted it. I noticed since, that the basic file that I thought was in that project, was in fact in another one I opened - due to the fact that closing does not include removing, which i originally expected. (I've still got the project file, I'll try and get it to you.)

[José Roca]

I generate an array of numbers and copy them to a text box with a vertical scroll bar. I've noticed that if the list is more than about a 1000 values, that said text box flickers a lot, but in most cases it eventually stabilizes, and I can then access the list by means of the scroll bars.

Assuming that you are using a loop, disable redrawing with SetWindowRedraw(<handle of the control>, FALSE) before starting the loop and enable it again when the loop ends with SetWindowRedraw(<handle of the control>, TRUE). If you aren't using a loop, then tell us what you're doing.

However, if I try to use the scroll bars before it stops flickering, a message pops up to the effect it is not responding. A list of 5000 items takes about 50 seconds for the text box to be usable, I gave up on 10,0000 items. It is not that obvious when the text box is complete, perhaps I need to add a bell, or whistle...

When using a tight loop, the control won't be responsible until the loop ends unles you allow Windows to process pending messages calling the procedure AfxDoEvents inside the loop.

[Paul Squires]

Sorry, Paul, bit of overlap in our posts. I've moved on from that original problem, not sure if I can find the project, may have deleted it. I noticed since, that the basic file that I thought was in that project, was in fact in another one I opened - due to the fact that closing does not include removing, which i originally expected. (I've still got the project file, I'll try and get it to you.)

Hi Ray, I got the two .wfbe project files that you emailed me. You are correct with your assessment of the problem. You had the file open at the same time in two different projects.

[José Roca]

The localization editor doesn't display correctly the translated phrase for languages like Russian or Chinese (it displays "?").