PlanetSquires Forums

Support Forums => WinFBE - Code Editor and Visual Designer => Topic started by: Paul Squires on January 18, 2019, 04:04:31 PM

Title: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 18, 2019, 04:04:31 PM
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).

Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: SeaVipe on January 18, 2019, 06:24:52 PM
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...
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 18, 2019, 06:49:23 PM
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.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: SeaVipe on January 18, 2019, 08:09:19 PM
Okay, that worked, thanks.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Joerg Buckel on January 19, 2019, 08:13:41 AM
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. :-)
Quote
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.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 19, 2019, 09:21:24 AM
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.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: James Fuller on January 19, 2019, 03:44:54 PM
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

Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 19, 2019, 05:19:07 PM
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
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: raymw on January 20, 2019, 09:13:09 AM
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
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 20, 2019, 12:18:05 PM
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.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: raymw on January 20, 2019, 12:21:19 PM
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...
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: raymw on January 20, 2019, 12:32:17 PM
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.)
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 20, 2019, 01:10:27 PM
Quote
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.

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

Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 20, 2019, 01:39:52 PM
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.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 20, 2019, 02:52:51 PM
The localization editor doesn't display correctly the translated phrase for languages like Russian or Chinese (it displays "????").
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 20, 2019, 03:19:06 PM
I wonder if the following may be the problem (issue with the font?) because I am using a unicode edit control (from CWindow). I will try setting a different font and see what happens......

https://stackoverflow.com/questions/7153340/russian-characters-not-showing-up-correctly-in-mfc-unicode-list-box

https://stackoverflow.com/questions/8742882/display-arabic-unicode-in-mfc-view?rq=1

Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: raymw on January 20, 2019, 03:48:52 PM
is the options - build configurations - working properly? It seems stuck on win32 console (release)
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 20, 2019, 04:01:33 PM
is the options - build configurations - working properly? It seems stuck on win32 console (release)
I fixed that yesterday if I remember correctly.... it was not saving between sessions. I will upload another package tonight if I get this Russian font thing figured out.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 20, 2019, 04:14:23 PM
When I switch to Russian and restart WinFBE, the entire application shows "??????" for text. I am wondering if it will require being on a Russian version of Windows. I do have #Define UNICODE defined for the compiled version of WinFBE.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 21, 2019, 03:13:17 AM
> I am wondering if it will require being on a Russian version of Windows.

No. It works in this test:

Code: [Select]
' ########################################################################################
' Microsoft Windows
' Contents: Demonstrates the use of the Edit control.
' Compiler: FreeBasic 32 & 64 bit
' Copyright (c) 2016 Josť Roca. Freeware. Use at your own risk.
' THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
' EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
' MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR PURPOSE.
' ########################################################################################

#define UNICODE
#INCLUDE ONCE "Afx/CWindow.inc"
#INCLUDE ONCE "Afx/CTextStream.inc"
USING Afx

CONST IDC_EDIT1 = 1001

DECLARE FUNCTION WinMain (BYVAL hInstance AS HINSTANCE, _
                          BYVAL hPrevInstance AS HINSTANCE, _
                          BYVAL szCmdLine AS ZSTRING PTR, _
                          BYVAL nCmdShow AS LONG) AS LONG

   END WinMain(GetModuleHandleW(NULL), NULL, COMMAND(), SW_NORMAL)

' // Forward declaration
DECLARE FUNCTION WndProc (BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM) AS LRESULT

' ========================================================================================
' Main
' ========================================================================================
FUNCTION WinMain (BYVAL hInstance AS HINSTANCE, _
                  BYVAL hPrevInstance AS HINSTANCE, _
                  BYVAL szCmdLine AS ZSTRING PTR, _
                  BYVAL nCmdShow AS LONG) AS LONG

   ' // Set process DPI aware
   AfxSetProcessDPIAware

   ' // Create the main window
   DIM pWindow AS CWindow
   pWindow.Create(NULL, "Edit controls", @WndProc)
   pWindow.SetClientSize 400, 200
   pWindow.Center

   ' // Add an Edit control
   DIM hEdit AS HWND = pWindow.AddControl("Edit", , IDC_EDIT1, "", 20, 15, 305, 23)

   ' // Set the focus in the first edit control
   SetFocus hEdit

dim idx as long
   ' // Create an instance of the CTextStream class
DIM pTxtStm AS CTextStream
' // Open file as a text stream
DIM cbsFile AS CBSTR = ExePath & $"\russian.lang"
DIM cbs AS CBSTR
IF pTxtStm.OpenUnicode(cbsFile) = S_OK THEN
   ' // Read the file sequentially
   DO UNTIL pTxtStm.EOS
      cbs = pTxtStm.ReadLine
      idx = idx + 1
      if idx > 20 then exit do
   LOOP
   pTxtStm.Close
END IF

DIM i as long
i = Instr(cbs, ":")
cbs = Mid(**cbs, i+1)
SetWindowText hEdit, cbs
cbs = rtrim(AfxStrParse(cbs, 1, ";"), any chr(9,32))


   ' // Dispatch Windows messages
   FUNCTION = pWindow.DoEvents(nCmdShow)

END FUNCTION
' ========================================================================================

' ========================================================================================
' Main window callback procedure
' ========================================================================================
FUNCTION WndProc (BYVAL hwnd AS HWND, BYVAL uMsg AS UINT, BYVAL wParam AS WPARAM, BYVAL lParam AS LPARAM) AS LRESULT

   SELECT CASE uMsg

      CASE WM_COMMAND
         SELECT CASE GET_WM_COMMAND_ID(wParam, lParam)
            ' // If ESC key pressed, close the application sending an WM_CLOSE message
            CASE IDCANCEL
               IF GET_WM_COMMAND_CMD(wParam, lParam) = BN_CLICKED THEN
                  SendMessageW hwnd, WM_CLOSE, 0, 0
                  EXIT FUNCTION
               END IF
         END SELECT

    CASE WM_DESTROY
         ' // End the application
         PostQuitMessage(0)
         EXIT FUNCTION

   END SELECT

   ' // Default processing of Windows messages
   FUNCTION = DefWindowProcW(hWnd, uMsg, wParam, lParam)

END FUNCTION
' ========================================================================================
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 21, 2019, 03:15:03 AM
I remember that it worked in a much older version. Don't know in which version started happening.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 21, 2019, 03:55:15 AM
The Chinese.lang file that comes with this package is bad. It is full of ???.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 21, 2019, 08:43:58 AM
> I am wondering if it will require being on a Russian version of Windows.

No. It works in this test:

Yes, your demo works on my system as well. Strange, because in WinFBE I am using the same type of code as you are to open and read the file. I am using the CTextStream class and CBSTR's. You can see this in the LoadLocalizationFile function in the modRoutines.inc file.

During startup, I load the "English.lang" into a global array gLangEnglish() and whatever localized file into the LL() array. The only difference being that the arrays are WSTRING * MAX_PATH rather than CBSTR but the conversion from CBSTR to WSTRING shouldn't make a difference, should it? I am a little perplexed by this problem so far.

Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Josť Roca on January 21, 2019, 11:27:50 AM
I have found the problem. The intrinsic FB string functions don't work with languages like Chinese and Russian if you rely in automatic conversion. I warned you about it regarding MID, but it also happens with other functions.

The only reliable way with the current versions of FB is to use ** because this way you access the string buffer directly, without conversions (and it is faster too).

So, instead of

cbs = rtrim(AfxStrParse(cbs, 1, ";"), any chr(9,32))

use

cbs = rtrim(**AfxStrParse(cbs, 1, ";"), any chr(9,32))

So get used to ** whem using FB intrinsic string functions.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 21, 2019, 11:33:44 AM
The problem appears to be when I apply RTRIM.

' FAIL
      gLocalPhrases(pp) = rtrim(AfxStrParse(wData, 1, ";"), any chr(9,32))
      AfxSetWindowText( GetDlgItem(HWND_FRMOPTIONSLOCAL, IDC_FRMOPTIONSLOCAL_CMDLOCALIZATION), gLocalPhrases(pp) )

' SUCCESS
      gLocalPhrases(pp) = AfxStrParse(wData, 1, ";")
      AfxSetWindowText( GetDlgItem(HWND_FRMOPTIONSLOCAL, IDC_FRMOPTIONSLOCAL_CMDNEW), gLocalPhrases(pp) )

' SUCCESS
      gLocalPhrases(pp) = wData
      AfxSetWindowText( GetDlgItem(HWND_FRMOPTIONSLOCAL, IDC_FRMOPTIONSLOCAL_CMDEDIT), gLocalPhrases(pp) )
 
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 21, 2019, 11:35:06 AM
LOL, we posted the same time  :-)

Thanks for researching it Jose. I will make sure to use ** with the FB intrinsic functions.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: SeaVipe on January 21, 2019, 03:00:19 PM
Hi Paul, Looking Good!

1.
Testing various items on the Version 1.8.8 list copied from GitHub. I like Snippets; nice and simple and works very well.

2.
F6 works on my machine but only after the subject file has been loaded into the editor.
Close the file(s) and F6 works okay with no need to perform the same file open/close on subsequent runnings of WinFBE.
Example: In an #Include file, this line functioned correctly when called from my test program:
Code: [Select]
? "Last Error: " + toStringFBerrorCodes( GetLastError() ) However, highlighting toStringFBerrorCodes and pressing F6 only popped up a file not found msgbox. Load the (#included) file (.bi) into the editor and then close it (the file now appears in Explorer/Header) and F6 opens the file and moves the cursor to the beginning of the function. I'm not sure if this is by design or not.

3.
Is there a way to set the colours for the 3 combo boxes to windows default or the Explorer panel or my choice? See the attached image.
Thanks.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: Paul Squires on January 21, 2019, 04:16:31 PM
Hi Clive,

The F6 functionality is designed to only work if the source code containing the sub/function being searched for is actually loaded in WinFBE (either in an open Tab, or as part of a Project).

I will change the colors for those comboboxes. I set them to equal the same color as the edit window (background/foreground/highlight) because I thought that people using different theme colors would like to have those comboboxes reflect the same type of colors. Personally, like you, I prefer the standard Windows colors. Maybe in the future I will allow a setting to color them different or a setting to toggle their visibility (show/hide).

Thanks for testing. I will upload a new test version shortly that has a new PictureBox control for the visual designer along with a few minor fixes I came across since the last draft upload. If this next draft goes okay then I will post a formal release in the next few days.
Title: Re: Are you adventurous? WinFBE 1.8.8 draft is ready....
Post by: SeaVipe on January 21, 2019, 04:48:41 PM
Thanks, Paul,
I assumed that all the includes would be searched when F6 was pressed but that could slow down the editor if there were a lot of files to search.


When you get to working on colour settings, any chance of special colours for user defined functions/types, WinAPI etc. I've manually added key words like GetTickCount and GetLastError to freebasic_keywords.txt which sort of works. I guess I got used to FF3's colouring scheme.