PlanetSquires Forums

Support Forums => PlanetSquires Software => Topic started by: Paul Squires on June 25, 2016, 05:07:40 PM

Title: WinFBE on GitHub
Post by: Paul Squires on June 25, 2016, 05:07:40 PM
I have created a Git repository for the WinFBE project. All source code is now there. It now makes it easy for me to commit changes to source code and have it available immediately to anyone who is interested.

https://github.com/PaulSquires/WinFBE

You will find a green button on that page called "Clone or download". Click that button and you will see an option to download the source in a zip file. This will get you the very latest source code and exe's.

For general stable releases you can find WinFBE releases at: https://github.com/PaulSquires/WinFBE/releases

Also, a general project comment thread is active over on the FreeBASIC community forums:  http://freebasic.net/forum/viewtopic.php?f=8&t=25215


Title: Re: WinFBE on GitHub
Post by: Petrus Vorster on June 25, 2016, 05:48:40 PM
The Rambo pic is much different from Einstein...LOL
:D
Title: Re: WinFBE on GitHub
Post by: Paul Squires on June 25, 2016, 06:32:57 PM
hahaha! Yeah, I need to change that  :)
Title: Re: WinFBE on GitHub
Post by: Eddy Van Esch on February 14, 2017, 05:03:35 AM
Paul,
I just recently found out about WinFBE (haven't tried it because I am not yet using FB ).
I was wondering how I should relate WinFBE  to FF for FB ...
Should I see WinFBE as a 'JellyFish for FB' ...?   :)

Kind regards
Title: Re: WinFBE on GitHub
Post by: Paul Squires on February 14, 2017, 08:38:04 AM
Yes for now WinFBE is like JellyFish for FB. I am building on WinFBE to eventually become FireFly for FB.
Title: Re: WinFBE on GitHub
Post by: José Roca on June 10, 2017, 11:38:54 PM
I can't repeat it at will, but it has happened to me several times: When doing searches using Ctrl+F, sometimes the Find dialog does not appear and the editor no longer allows to edit text.
Title: Re: WinFBE on GitHub
Post by: José Roca on July 08, 2017, 07:15:49 PM
Check the code to save a file. Each time I save the code, a bunch of "Invalid parameter passed to a C runtime function" messages appear in DebugView.
Title: Re: WinFBE on GitHub
Post by: Petrus Vorster on July 09, 2017, 02:31:52 PM
QuoteYes for now WinFBE is like JellyFish for FB. I am building on WinFBE to eventually become FireFly for FB.

The combination of your work would be an awesome adventure in a new Firefly.
Although i am worried about the apparent decline in interest in the FB project over there, I would really like to see a new Firefly in 64bit.

I have played with .Net and its slow, creepy and no fun at all.
Too much stuff to drag along, to little enjoyment and zero fun for a hobbyist.

I hope you all push through and we have a great tool to last us a few more years!!!

Thanks for the efforts, it much appreciated.
Title: Re: WinFBE on GitHub
Post by: José Roca on July 10, 2017, 05:54:43 PM
@Paul,

When I click the "Comment Block" toolbar button, it REMs also the blank lines. I think that it should leave the blank lines unaltered.
Title: Re: WinFBE on GitHub
Post by: José Roca on July 10, 2017, 08:03:07 PM
@Paul,

Maybe you could check if, when compiling as GUI, if there are some incompatible console only FB statements and either switch to console compilation or display a warning and don't compile. SLEEP, for example, is very annoying because the application remains in memory and you have to kill it using the Task Manager.
Title: Re: WinFBE on GitHub
Post by: Pierre Bellisle on July 10, 2017, 09:38:30 PM
Or maybe put the info explicitly in the file.
This is what I use in my pre-compiler and I find this a real nice click saver...

Note: I use "< as left delimiter and >" as right delimiter.

#Define JumpSourceFile "<D:\Free\Code.bas>" 'In a basic file
or
//#Define JumpSourceFile "<D:\Free\Code.bas>" //In a rc or XML file
Could be used in any file open in the IDE telling what main file to compile.
To avoid conflict in opened related files, put a suffix to "JumpSourceFile", like...
#Define JumpSourceFile01 "<D:\Free\Code.bas>"
#Define JumpSourceFile02 "<D:\Free\Code.bas>"
Everything starting with #Define JumpSourceFile will be considered. #Undef may also be used.

#Define JumpCompiler "<D:\Free\64\fbc.exe>"
Say wich compiler to use, 32bit, 64bit or DOS

#Define JumpCompilerCmd "<-s gui -w pedantic -i D:\Free\Roca\ "D:\Free\bas\Default.rc">"

The command line to send to the compiler.

#Define JumpExeCmd "<MyCommandLine ForTheCompiledExe>"
Command line to pass to the compiled exe at run time.

#Define JumpOption "<ShowInfo ShowLog>"
ShowInfo give Jump.exe infos taken while running Jump.exe for debug purpose.
ShowLog  Show the result log even if no errors or warning have occured for debug purpose.

Pierre
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 13, 2017, 10:01:25 AM
Quote from: Jose Roca on July 10, 2017, 05:54:43 PM
@Paul,

When I click the "Comment Block" toolbar button, it REMs also the blank lines. I think that it should leave the blank lines unaltered.


Thanks Jose, I have this implemented and will upload the change this evening.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 13, 2017, 10:12:34 AM
Quote from: Jose Roca on July 08, 2017, 07:15:49 PM
Check the code to save a file. Each time I save the code, a bunch of "Invalid parameter passed to a C runtime function" messages appear in DebugView.


That's interesting. I will download DebugView tonight and see if I can get the same results as you have. The Save code is basically in the clsDocument.SaveFile function. Maybe it is related to the PUT #f code in there that is pushing the code to the file. I might have to do some CASTing although the compiler does not issue any warnings.

Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 13, 2017, 10:23:46 AM
Quote from: Jose Roca on July 10, 2017, 08:03:07 PM
@Paul,

Maybe you could check if, when compiling as GUI, if there are some incompatible console only FB statements and either switch to console compilation or display a warning and don't compile. SLEEP, for example, is very annoying because the application remains in memory and you have to kill it using the Task Manager.


Hi Jose, I see what Pierre has done and it is somewhat similar to the approach I took with Jellyfish Editor to include embedded directives in the code to handle certain tasks. To date, I have tended to stay away from this type of embedding with WinFBE but I can certainly start adding things now.

How about something like this:

'#CONSOLE ON|OFF

Console ON will eliminate adding the "-s gui" command to the compile line.

I will add it and you can see if it is effective in helping your situation.
Title: Re: WinFBE on GitHub
Post by: José Roca on July 13, 2017, 03:07:45 PM
Pierre's approach is targeted to the use of UltraEdit. I don't think that your users would like it for general options. It is better to set the options in dialogs.

However, for hacks like CONSOLE ON, that will be fine.

BTW the most annoying problem that I'm having is with the Find option. After using the Find dialog several times (more than a few times, but less than many times), the cursor disppears and I have to restart the compiler. It is as if it has entered in a loop.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 13, 2017, 04:56:11 PM
...I will dive deep into the Find dialog and fix whatever is wrong  :)
Title: Re: WinFBE on GitHub
Post by: José Roca on July 13, 2017, 05:59:10 PM
Pierre's suggestion could also been used effectively to override the compiler options, specially when compiling a file that does not belong to a project.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 13, 2017, 09:24:54 PM
Quote from: Jose Roca on July 08, 2017, 07:15:49 PM
Check the code to save a file. Each time I save the code, a bunch of "Invalid parameter passed to a C runtime function" messages appear in DebugView.


I ran DebugView++ and this also happens when you simply create a "New" file. This will be hard to track down and could be something deep in the compiler generated code or simply something in my code. A tough one.
Title: Re: WinFBE on GitHub
Post by: José Roca on July 15, 2017, 01:51:01 AM
I always test my code with DebugView activated. Not only allows me to display my own messages, but also dispays messages sent by system DLLs. It has spared me more than one headache.

I have tried opening a file in binary mode and writing to it and it does not throw any exception. As always, the usual suspects are pointers.

Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 15, 2017, 11:06:13 PM
Quote from: Jose Roca on July 15, 2017, 01:51:01 AM
I always test my code with DebugView activated. Not only allows me to display my own messages, but also dispays messages sent by system DLLs. It has spared me more than one headache.

I have tried opening a file in binary mode and writing to it and it does not throw any exception. As always, the usual suspects are pointers.


The problem was my call to _stricmp in clsDBEngine.dbDelete
I have changed the code to now simply compare the two filenames using UCASE instead of _stricmp.

I have also added a "Mixed Case" keyword casing option.

GitHub release 1.3.5 uploaded.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 15, 2017, 11:23:35 PM
Quote from: Jose Roca on July 13, 2017, 03:07:45 PM
BTW the most annoying problem that I'm having is with the Find option. After using the Find dialog several times (more than a few times, but less than many times), the cursor disppears and I have to restart the compiler. It is as if it has entered in a loop.

I am looking into this one now. I have added a bit of code to the find/replace code. You should install the 1.3.5 release and then download the raw WinFBE exe's from GitHub (as the code addition is not in the 1.3.5 release but is in the raw exe's).
Title: Re: WinFBE on GitHub
Post by: Pierre Bellisle on August 10, 2017, 09:49:10 PM
Hey Paul,

If I may ask, what _stricmp() couldn't do that UCASE() can?
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 10, 2017, 11:46:41 PM
I must have been calling _stricmp incorrectly because DebugView was reporting errors calling the api. Rather than risk errors in the code I simply changed to using UCASE rather than the string insensitive compare. It must have been that particular choice of variable types that I was comparing because I also use _stricmp elsewhere in the WinFBE codebase and no errors are thrown in those cases.
Title: Re: WinFBE on GitHub
Post by: José Roca on August 15, 2017, 06:37:44 PM
There is still a cosmetic problem with the Find/Replace dialog when used with a DPI <> 96 (I'm using 192). The icons are being drawn bigger that they should and if it not was for the tooltips you will never guess what they do. See capture below.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 15, 2017, 08:37:02 PM
Hi Jose, yes, I was aware of that problem. I believe I need to create multiple versions of the icon so that it will scale better.
Title: Re: WinFBE on GitHub
Post by: José Roca on August 31, 2017, 03:00:16 AM
A couple of suggestions:

1.- Asking before exiting the editor should be optional, i.e. in Code Editor Options
- Ask before exiting the editor?

2.- Another option
- Allow multiple instances?

Currently, if I register an extension (e.g. bas) with the editor, each time I double click a .bas file in explorer a new instance of the editor is launched to load the file. If "Allow multiple instances?" is unchecked, the file should be loaded in the active instance of the editor, instead of launching a new one.

To check if it is already an instance of the editor running, you can use something like:


IF AllowMultipleInstances = FALSE THEN
   hWindow = FindWindow("WinFBE_Class", NULL")
   IF hWindow THEN
      SetForegroundWindow hWindow
      ProcessCommandLine(hWindow)
      FUNCTION = -1
      EXIT FUNCTION
   END IF
END IF


To process the the command line, in the CSED editor I use:


' ========================================================================================
' Gets the command line and processes it
' ========================================================================================
SUB CSED_ProcessCommandLine (BYVAL hwnd AS DWORD)

   LOCAL strFileName   AS STRING           ' // File name
   LOCAL strLineNumber AS STRING           ' // Line number
   LOCAL DataToSend    AS COPYDATASTRUCT   ' // Data to send structure

   IF ISFALSE hwnd THEN EXIT SUB

   IF IsIconic(hwnd) <> 0 OR IsZoomed(hwnd) <> 0 THEN ShowWindow hwnd, %SW_RESTORE
   SetForegroundWindow hwnd

   IF TRIM$(COMMAND$) = "" THEN EXIT SUB

   strLineNumber = RIGHT$(COMMAND$, LEN(COMMAND$) - INSTR(-1, COMMAND$, " "))
   IF LEN(TRIM$(strLineNumber, ANY "0123456789")) THEN
      strFileName = TRIM$(COMMAND$, ANY $DQ + $SPC)
   ELSE
      strFileName = TRIM$(LEFT$(COMMAND$, LEN(COMMAND$) - LEN(strLineNumber)), ANY $DQ + $SPC)
   END IF

   IF TRIM$(strFilename) = "" THEN EXIT SUB

'   IF strFileName <> "" AND PATHNAME$(PATH, strFileName) = "" THEN
'      FBSED_MsgBox hwnd, "Missing path in file " & strFileName, %MB_OK OR %MB_ICONERROR, "Error"
'      EXIT SUB
'   END IF

   IF strFileName <> "" AND PATHNAME$(PATH, strFileName) = "" THEN strFileName = CURDIR$ & "\" & strFileName

   IF ISFALSE AfxFileExists(strFileName) THEN
      FBSED_MsgBox hwnd, "Can't find the file " & strFileName, %MB_OK OR %MB_ICONERROR, "Error"
      EXIT SUB
   END IF

   DataToSend.lpData  = STRPTR(strFileName)
   DataToSend.cbdata  = LEN(strFileName) + 1
   DataToSend.dwData  = VAL(strLineNumber) - 1

   SendMessage hwnd, %WM_COPYDATA, LEN(DataToSend), VARPTR(DataToSend)
   IF pSed.hEdit THEN SCI_GotoLine(pSed.hEdit, VAL(strLineNumber) - 1)

END SUB
' ========================================================================================


and in the WM_COPY message processing:


      CASE %WM_COPYDATA
         pDataToGet = lParam
         pszBuffer = @pDataToGet.lpData
         CSED_OpenFile TRIM$(@pszBuffer)
         SCI_GotoLine(pSed.hEdit, SCI_GetTextLength(pSed.hEdit))
         SCI_GotoLine(pSed.hEdit, @pDataToGet.dwData)


This is also useful for tools like FileSearch that display a list of finds and allow to load the file in the editor an position the cursor in the selected line.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 31, 2017, 09:22:47 AM
Thanks Jose, I will modify my command line processing code to include yours so that incoming files can be opened in existing instances of the editor.

I am not understanding your "Ask before exiting the editor?" question. I already have that option listed in "Options", "Environment Options", General Options". Is it not working correctly?
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 31, 2017, 11:27:46 AM
Quote from: Jose Roca on August 31, 2017, 03:00:16 AM
2.- Another option
- Allow multiple instances?

Currently, if I register an extension (e.g. bas) with the editor, each time I double click a .bas file in explorer a new instance of the editor is launched to load the file. If "Allow multiple instances?" is unchecked, the file should be loaded in the active instance of the editor, instead of launching a new one.
I have this implemented now. Appears to be working perfectly. This is a very nice change and addition. Thanks for the suggestion and code!
I will upload a new release this evening (v1.4.9).

Title: Re: WinFBE on GitHub
Post by: José Roca on August 31, 2017, 11:48:08 AM
Quote from: Paul Squires on August 31, 2017, 09:22:47 AM
Thanks Jose, I will modify my command line processing code to include yours so that incoming files can be opened in existing instances of the editor.

I am not understanding your "Ask before exiting the editor?" question. I already have that option listed in "Options", "Environment Options", General Options". Is it not working correctly?


Sorry, I was looking for it in the wrong place.
Title: Re: WinFBE on GitHub
Post by: José Roca on August 31, 2017, 11:49:23 AM
Quote from: Paul Squires on August 31, 2017, 11:27:46 AM
Quote from: Jose Roca on August 31, 2017, 03:00:16 AM
2.- Another option
- Allow multiple instances?

Currently, if I register an extension (e.g. bas) with the editor, each time I double click a .bas file in explorer a new instance of the editor is launched to load the file. If "Allow multiple instances?" is unchecked, the file should be loaded in the active instance of the editor, instead of launching a new one.
I have this implemented now. Appears to be working perfectly. This is a very nice change and addition. Thanks for the suggestion and code!
I will upload a new release this evening (v1.4.9).



Do you have used unicode? I have noticed that I was using ansi in the code posted.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 31, 2017, 12:27:18 PM
Yes, I used Unicode and it works okay with Unicode. I just had to ensure that I was sending the proper length of the string to WM_COPYDATA. Basically, 2x the LEN of the string.
Title: Re: WinFBE on GitHub
Post by: Richard Kelly on August 31, 2017, 04:19:26 PM
I know it's early in the visual designer stuff. Just wondering if you plan on supporting opacity as a form attribute? There are times, like splash screens, where I like to fade in and out.

Rick
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 31, 2017, 05:41:36 PM
Quote from: Richard Kelly on August 31, 2017, 04:19:26 PM
I know it's early in the visual designer stuff. Just wondering if you plan on supporting opacity as a form attribute? There are times, like splash screens, where I like to fade in and out.

Rick
Everything is on the table at this point. Long ways to go before we get to the code generation stage.
Title: Re: WinFBE on GitHub
Post by: Richard Kelly on December 05, 2017, 11:04:30 PM
Downloaded the latest version. Being a bit careful, I ran all my cCalendar work both 32/64 bit with FB 1.05 and FB 1.06 with no issues. Loaded my SQLite Client/Server work in progress with no issues.

Compiled the piano example and that was nice.

After a few hours, no crashes, rock solid.

When you get the designer going, I have code for a GUI cCalendar I'll port over, test, and, let you know the results.

Rick Kelly

8)
Title: Re: WinFBE on GitHub
Post by: José Roca on May 12, 2018, 06:29:23 PM
Disabling "Autocomplete" does not work with SELECT CASE. It insists in adding "CASE" after pressing the Enter key.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 12, 2018, 06:44:11 PM
Quote from: José Roca on May 12, 2018, 06:29:23 PM
Disabling "Autocomplete" does not work with SELECT CASE. It insists in adding "CASE" after pressing the Enter key.

Right you are. In the modAutoInsert.inc file I tested for AutoIndentation instead of AutoComplete. Oops :)

function AttemptAutoInsert() as Long
   If gConfig.AutoIndentation = false Then exit function

I will fix that.
Title: Re: WinFBE on GitHub
Post by: José Roca on May 26, 2018, 11:23:11 AM
With IF xxx THEN, FOR, WHILE, DO, etc., and autocomplete disabled, the editor adds extra blank lines, the difference being that it doesn't add NEXT, DO, END IF, etc.

When saving a file as UTF and reloading it, it adds some garbage at the end, e.g.:


print
print "Press any key..."
sleep
␀ԉ�ԛ鯵䁡耀

Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 26, 2018, 12:22:21 PM
Quote from: José Roca on May 26, 2018, 11:23:11 AM
With IF xxx THEN, FOR, WHILE, DO, etc., and autocomplete disabled, the editor adds extra blank lines, the difference being that it doesn't add NEXT, DO, END IF, etc.

When saving a file as UTF and reloading it, it adds some garbage at the end, e.g.:


print
print "Press any key..."
sleep
␀ԉ�ԛ鯵䁡耀


Hi Jose, I'm not seeing either of those behaviours with the version I am using. I will upload to github the latest code and exe's and then you can try again with the tests to see if the problem is still there.
(I just need to fix the Function List problem of not showing the SUBS)
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 26, 2018, 12:54:18 PM
Just uploaded v1.6.1 for you to try.
https://github.com/PaulSquires/WinFBE/releases
Title: Re: WinFBE on GitHub
Post by: José Roca on May 26, 2018, 01:09:17 PM
This version works fine.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 26, 2018, 01:54:07 PM
Excellent - thanks Jose :)
Title: Re: WinFBE on GitHub
Post by: José Roca on May 27, 2018, 10:43:12 AM
Now what it does not work is Autoindentation.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 27, 2018, 11:41:43 AM
....right you are. I completely closed off Autoindentation by testing if AutoComplete is active. I will fix that right now.
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 27, 2018, 12:14:01 PM
Hi José,

I have reworked the code to test for AutoIndentation and AutoCompletion. It appears to work much better now and should also eliminate the extra CR/LF when using AutoIndentation only.

I have attached new 32 and 64 exes for you to try. I will upload the changes to GitHub if you report back that those exe's are working as you expect.
Title: Re: WinFBE on GitHub
Post by: José Roca on May 27, 2018, 12:39:59 PM
Yes, it works as expected.
Title: Re: WinFBE on GitHub
Post by: José Roca on May 27, 2018, 11:29:45 PM
... but with SELECT CASE.
Title: Re: WinFBE on GitHub
Post by: José Roca on May 29, 2018, 04:23:52 PM
The editor crashes if I try to load shobjidl.bi in it. Must be a parsing problem.
Title: Re: WinFBE on GitHub
Post by: Marc Pons on May 31, 2018, 11:25:50 AM
Hi Paul,

I've finally tested your very nice editor...
Great Job
I wanted to get it in French, so here my translation as I understood the process

I've noticed few points   

00122:Show left margin   for me it would be >   Show marging Bookmarks
00127:Tab Size:       i don't understand why the ':'  or  that textbox not well positionned  ( and for french  'Taille de tabulation'   does not fit)
Title: Re: WinFBE on GitHub
Post by: Paul Squires on May 31, 2018, 01:53:24 PM
Excellent - thanks Marc, really appreciate the French translation. I am adding it to the distribution.
Title: Re: WinFBE on GitHub
Post by: ChrisC on July 27, 2018, 01:47:44 AM
Hello Paul

i have downloaded your latest WinFBE suite dated Jul 22 2018

and when i execute the WinFBE64.exe  --> i got the error message  "WinFBE has stopped working "

Title: Re: WinFBE on GitHub
Post by: ChrisC on July 27, 2018, 01:49:55 AM
how to resolve this issue?

same thing also happen to the winFBE32.exe ?
Title: Re: WinFBE on GitHub
Post by: raymw on July 27, 2018, 07:09:06 AM
Hi Chris, there is a later version, (dated 25th July) on github. some had problems with the earlier version http://www.planetsquires.com/protect/forum/index.php?topic=4178.0 (http://www.planetsquires.com/protect/forum/index.php?topic=4178.0)
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 27, 2018, 08:56:05 AM
I will upload a new complete package either tonight (July 27) or tomorrow. Just need to re-engineer the prepares codetips in order to avoid that GPF issue users have been experiencing. In the meantime, simply edit the WinFBE.ini and set codetips = 0
Title: Re: WinFBE on GitHub
Post by: ChrisC on July 27, 2018, 10:40:30 AM
thanks all
downloaded the Jul 25 and set codetips=0  and now it is working
Title: Re: WinFBE on GitHub
Post by: raymw on July 27, 2018, 10:43:07 AM
Hi Paul, can you put in a txt list of properties you've listed, but not yet implemented for the various designer tools e.g. button textmargin (and I think you need property for button backcolordown.

added - also in edit, selection of copy,cut, paste not working, although cntrl c etc ok.
Title: Re: WinFBE on GitHub
Post by: ChrisC on July 29, 2018, 02:29:09 PM
thanks Paul

Your WinFBX is absolutely awesome, hope that you can come up with a similar IDE for Oxygenbasic

the combination of WinFBE and WinFBX is the best combination for FB development in windows environment
Title: Re: WinFBE on GitHub
Post by: ChrisC on July 29, 2018, 03:52:25 PM
Maybe add more information on your tooltips for the icon bar

for example  at the Top left button on the icon bar  --> set the tooltips  as  Create  New file using templates (Ctr + N )
                                                                      instead of just  New (Ctr + N )

this is especially true if the user is a beginner like myself
Title: Re: WinFBE on GitHub
Post by: raymw on July 29, 2018, 07:06:34 PM
There seems to be something odd with the right mouse button. The copy/paste/etc menu worked earlier today, then I copied some code from notepad, and could not paste using mouse. this was in winfbe32. I opened winfbe64 and right button menu worked fine in there.  I restarted fbe32, still not working, rebooted machine, still not working in winfbe32, but ok in winfbe64.. This is in the so-called operating system known as windows10. This morning, the shortcuts to winfbe had disappeared, and the programs would not run, as in earlier version. I opened the ini file, and it was empty!. In the past, windows updates have removed shortcuts and other stuff, but I don't think that is what has happened in this case. Is there an ini or other setting for the mouse right button?
Title: Re: WinFBE on GitHub
Post by: Paul Squires on July 29, 2018, 08:13:31 PM
Hi Ray, that was an error in the code. I have it fixed now. Thanks for pointing out the problem.
Title: Re: WinFBE on GitHub
Post by: José Roca on August 16, 2018, 12:21:00 AM
I have installed the latest WinFBE suite and tried the visual designer, but when I drag and drop one control, nothing happens and the selection goes to "Pointer".
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 16, 2018, 11:37:41 AM
Hi Jose, you don't drag and drop the controls (although that does seem like a logical way to do it). You select the Tool (control) from the Toolbox by clicking on it, and then you draw the rectangle area with your mouse. When you release the mouse button, the control should be created. Eventually I will implement the creation method of double-clicking on the Tool to automatically create the control on the form in the upper left position.
Title: Re: WinFBE on GitHub
Post by: José Roca on August 16, 2018, 05:51:10 PM
In fact, I prefer this way. Just didn't know.
Title: Re: WinFBE on GitHub
Post by: raymw on August 17, 2018, 05:55:55 PM
Probably wouldn't be too much trouble, but would a snap grid be useful?
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 17, 2018, 06:00:52 PM
I am working on a snap to grid but more so using alignment lines like you see in the more modern ide's these days. I put it on hold until I get all of the controls implemented because the controls are more important at this point. I almost have the OptionButton code implemented and then I will do the "Frame" control because that one should be easy. We'll then be able to nice visual option button groups.
Title: Re: WinFBE on GitHub
Post by: SeaVipe on August 17, 2018, 06:27:40 PM
Is there a grid control on the horizon?
Title: Re: WinFBE on GitHub
Post by: Paul Squires on August 17, 2018, 09:13:36 PM
Certainly not in the immediate future but it is definitely a control that I need to write or modify an existing one for use in the designer.

Until then....  http://www.planetsquires.com/protect/forum/index.php?topic=4033.msg30239
Title: Re: WinFBE on GitHub
Post by: José Roca on September 11, 2018, 08:23:04 AM
Version 1.7.9 no longer honors the WinFBXPath= override.

I have manually changed it to WinFBXPath=.\Programs\WinFBX

[Compiler]
FBWINCompiler32=.\FreeBASIC-1.06.0\fbc32.exe
FBWINCompiler64=.\FreeBASIC-1.06.0\fbc64.exe
CompilerSwitches=-w pedantic -v -showincludes
CompilerHelpfile=.\Help\freebasic_manual.chm
Win32APIHelpfile=.\Help\win32_fb.chm
WinFBXHelpfile=.\Help\WinFBX.chm
RunViaCommandWindow=0
WinFBXPath=.\Programs\WinFBX

yet, when I compile, the log file says

C:\Programs\WinFBE_Suite\FreeBASIC-1.06.0\inc\Afx\CWindow.inc
C:\Programs\WinFBE_Suite\FreeBASIC-1.06.0\inc\Afx\AfxCtl.inc

etc.
Title: Re: WinFBE on GitHub
Post by: José Roca on September 11, 2018, 08:55:20 AM
It seems that I have to use a fully qualified path:

WinFBXPath=C:\Programs\WinFBX