PlanetSquires Forums

Support Forums => WinFBE - Code Editor and Visual Designer => Topic started by: Paul Squires on May 31, 2020, 04:47:42 PM

Title: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on May 31, 2020, 04:47:42 PM
Version 2.1.7 (May 31, 2020)
Editor:
- Added: Occurrences Highlighting. Editor will highlight words under the current cursor position (Visual Studio has this type of feature as well).
- Changed: Changed the default toolchain to: FreeBASIC-1.07.1-gcc-8.4
- Fixed: Performance issue with parsing document when about to show a popup Autocomplete list.

Visual Designer:
- Fixed: Listbox control not consistently updating display visually during add or remove.

Download from: https://github.com/PaulSquires/WinFBE/releases
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: SeaVipe on June 01, 2020, 01:16:30 PM
Thanks, Paul! Occurrences Highlighting is a nice feature.
When using a dark or black background, a fairly bright colour is required to both be noticeable in other occurrences and also to be able to see the text colour of the highlighted word. I tried most colours in the colour picker (except Custom) and settled on Signal Green.
A couple of anomalies: Double apostrophes (double single quotes, '') is considered a word and Brace Highlighting is no longer functioning.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: SeaVipe on June 01, 2020, 03:09:42 PM
Hi Paul, Is there a Button TextForeColorHot property? The Autocomplete lists 2 TextForeColor properties for a button control. I'm currently using MouseEnter/MouseLeave Events to change the TextForeColor property.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 01, 2020, 09:20:36 PM
Thanks, Paul! Occurrences Highlighting is a nice feature.
When using a dark or black background, a fairly bright colour is required to both be noticeable in other occurrences and also to be able to see the text colour of the highlighted word. I tried most colours in the colour picker (except Custom) and settled on Signal Green.
A couple of anomalies: Double apostrophes (double single quotes, '') is considered a word and Brace Highlighting is no longer functioning.
That's odd, brace highlighting seems to be working okay for me here. Both 32 and 64 bit WinFBE's. I am thinking of adding a slider for degree of alpha blending for the brace colors. That should make it easier to customize the color better.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 01, 2020, 09:24:47 PM
Hi Paul, Is there a Button TextForeColorHot property? The Autocomplete lists 2 TextForeColor properties for a button control. I'm currently using MouseEnter/MouseLeave Events to change the TextForeColor property.
I remember us discussing this over on this thread: https://www.planetsquires.com/protect/forum/index.php?topic=4432.0
There currently is no TextForeColorHot. Here are the text color properties:

      Declare Property TextForeColor() As COLORREF
      Declare Property TextForeColor( ByVal nValue As COLORREF)
      Declare Property TextBackColor() As COLORREF
      Declare Property TextBackColor( ByVal nValue As COLORREF)
      Declare Property TextForeColorDown() As COLORREF
      Declare Property TextForeColorDown( ByVal nValue As COLORREF)
      Declare Property TextBackColorDown() As COLORREF
      Declare Property TextBackColorDown( ByVal nValue As COLORREF)
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: SeaVipe on June 01, 2020, 09:32:56 PM
I have BackColorHot as well, I thought adding ForeColorHot would make a nice pair! :0)
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Joerg Buckel on June 02, 2020, 08:43:13 AM
Hello Paul
The code completion does not work for me since the update to version 2.1.7. Can you take a look at it?
With version 2.1.6 I had no problems.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 02, 2020, 09:34:36 AM
Thanks Joerg, does it not work in 32 bit and 64 bit? Does it not work in Visual Designer related projects and non- VD projects? Standalone code outside of a project? Do you Tabs, or Tabs to Spaces? I made a lot of changes to the code and hopefully did not break something very important.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Joerg Buckel on June 02, 2020, 10:42:13 AM
Hello Paul

I don't know what's going on now.

It didn't work for me over Whitsun.

Today I'm in the office and the code completion wanted nothing to do with me again....
Now I started the 32bit version of WinFBE and the code completion worked.

Then I started the 64bit variant of WinFBE and ..... the code completion worked this time too.
No matter why. It works at the moment. If the behavior occurs again, I can give you detailed information.

Sometimes I get the feeling that it is only up to me...  ;D
I have worked with the 64bit version.
A new small project with Visual Designer.
So far it was only "standalone" code within the project.
I had not used Tabs, or Tabs to Spaces until now.

But as I mentioned before, this feature does not appear since the start of the 32bit variant.

But as mentioned I can't explain it.

 
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: raymw on June 14, 2020, 05:40:36 PM
Hi Paul, just a note but the compiler setup help files prefilled with your file locations.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: SeaVipe on June 15, 2020, 06:11:22 PM
Hi Paul, the wfxDateTimePicker font is fixed at runtime but editable at design time.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 16, 2020, 08:21:20 AM
Thanks Ray and Clive - I will look at both issues for the next update.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: philbar on June 17, 2020, 09:17:38 PM
Hi Paul. Thanks for letting me join the forum.

You probably thought you squashed this several releases back, but actually it just ran into a darker corner. If you define a TYPE inside an event routine, the Designer will duplicate the event function at the bottom of the page. There's an obvious workaround -- don't define TYPEs in event routines -- but it might be a symptom of something deeper. I think I've attached a screenshot.

Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 18, 2020, 07:55:38 AM
Thanks Phil - I'll definitely look into this one and fix it up.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: raymw on June 25, 2020, 08:13:56 PM
Hi Paul, just another little niggle, but others may not see it as such, but I do not like the autocomplete of adding the closing ')' for functions. More often than not I've got to delete it.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 25, 2020, 08:59:41 PM
Hi Ray - you can disable that feature in the editor settings.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: SeaVipe on June 26, 2020, 02:57:47 AM
:0)
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: raymw on June 26, 2020, 05:49:52 AM
Ok Paul, got it - disable character auto complete. thanks
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 26, 2020, 09:21:33 AM
Hi Paul, the wfxDateTimePicker font is fixed at runtime but editable at design time.
This is now fixed and will be in the next update.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 26, 2020, 09:22:19 AM
Hi Paul, just a note but the compiler setup help files prefilled with your file locations.
Ah, yes, this was in the WinFBE source tree and is now removed.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 26, 2020, 09:58:52 AM
Hi Paul. Thanks for letting me join the forum.

You probably thought you squashed this several releases back, but actually it just ran into a darker corner. If you define a TYPE inside an event routine, the Designer will duplicate the event function at the bottom of the page. There's an obvious workaround -- don't define TYPEs in event routines -- but it might be a symptom of something deeper. I think I've attached a screenshot.

Hi Phil, yes you're right that this is indeed a WinFBE parser problem. I looked at the code and the logic was built such that TYPE's were defined outside of Function/Sub blocks. It would be a lot of work and could break code if I try to rearrange that logic at this point so I agree with you that the best approach is for users not to define TYPE's within Function/Sub blocks. I honestly have never done that myself - that's probably why I never built it into the parser logic.

Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: philbar on June 26, 2020, 12:19:29 PM

Hi Phil, yes you're right that this is indeed a WinFBE parser problem. I looked at the code and the logic was built such that TYPE's were defined outside of Function/Sub blocks. It would be a lot of work and could break code if I try to rearrange that logic at this point so I agree with you that the best approach is for users not to define TYPE's within Function/Sub blocks. I honestly have never done that myself - that's probably why I never built it into the parser logic.
Thanks, Paul. I can live with that. I don't feel like an expert with FreeBasic yet, or even a talented amateur, so I'm still looking around for a style that suits me.

Just to be annoying, here are some other things I've noticed that I hope are easier:
1. UDTs allocated with STATIC instead of DIM don't get dropdowns.
2. SCOPE doesn't seem to get autocompleted or indented.
3. The Backcolor property on Frames, Checkboxes, and Radio buttons doesn't seem to do anything.

Sorry.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Bumblebee on June 26, 2020, 01:42:07 PM
I'm having some tab/focus issues.
In the attached project, the List box does not receive focus when the form is shown.
Loading an image, clicking on the image, or on the label does not steal focus from the list box - as it should.
Pressing the tab key however, removes focus.
Pressing it again, restores focus.
Minimizing the window, then restoring it, steals focus.
Switching to another application window, then returning to the test window, steals focus.
Overall, is not expected behavior for this window.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Bumblebee on June 27, 2020, 08:25:55 AM
Small issue, may be Windows 7 specific:
When I disable a list box, the background is not greyed out.
Disabled text box is greyed out.
Controls are 3D.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Josť Roca on June 27, 2020, 08:35:28 AM
> When I disable a list box, the background is not greyed out.

This is Windows normal behaviour.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 27, 2020, 09:09:06 AM
> When I disable a list box, the background is not greyed out.

This is Windows normal behaviour.

Yes, I believe the background should not get grayed out but the text color should be grayed. It isn't in WinFBE because I have implemented the Listbox as OwnerDraw and have not taken into consideration an alternate color for foreground text when the Listbox is disabled. I've put that on my to do list.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 27, 2020, 09:34:40 AM
I'm having some tab/focus issues.
In the attached project, the List box does not receive focus when the form is shown.
Loading an image, clicking on the image, or on the label does not steal focus from the list box - as it should.
Pressing the tab key however, removes focus.
Pressing it again, restores focus.
Minimizing the window, then restoring it, steals focus.
Switching to another application window, then returning to the test window, steals focus.
Overall, is not expected behavior for this window.

From what I can observe, looks like you after you have loaded all of the listbox items you have not selected any. If none are selected, then when the listbox gets focus it has nothing to highlight. Pressing the down arrow would move the focus to the first item and then you would see the highlighted item.

I would load your listbox in the Load event (rather than the FormReady), but in the FormReady event I'd set the focus to the Lsitbox just in case the focus got stolen away during the for creation.

Code: [Select]
''
''
Function Form1_Load( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
     ' // Add an image control
   dim pWindow as CWindow ptr = AfxCWindowPtr(sender.hWindow)
   if pWindow then
      pImageCtx = new CImageCtx(pWindow, IDC_IMAGECTX,, 0, 0, 500, 500)
      if pImageCtx then
         pImageCtx->SetImageAdjustment(GDIP_IMAGECTX_ACTUALSIZE)
         pImageCtx->SetBkColor(32000)
         pImageCtx->SetBkColorHot(32000)
      end if
   end if

  dim n as integer
  for n = 1 to 30
    form1.List1.Items.Add("Listbox item " & str(n))
  next n
 
  ' Set the selected item to be the first item
  form1.List1.SelectedIndex = 0

  Function = 0
End Function

''
''
Function Form1_FormReady( ByRef sender As wfxForm, ByRef e As EventArgs ) As LRESULT
  Form1.List1.Focused = true
  Function = 0
End Function
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Bumblebee on June 28, 2020, 07:35:49 AM
I implemented your changes and the problem persists.
You should be able to observe a focus loss after an item is selected. I'm seeing this in several projects that don't involve the Ctx control.
On these windows it may be difficult to see since the focus trace line isn't visible on a list box item.

1. I select an item in the list box.
2. I press tab.
3. I notice I cannot select another item by pressing the arrow keys, or by rotating the mouse wheel. I notice that the tab control did not receive focus.
4. I press tab.
5. Focus is returned to the list box, as I can now do what I described in step 3.

This may be trivial for mouse users who click on everything, but for keyboard users this is weird.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Bumblebee on June 28, 2020, 07:50:59 AM
It appears that when the back color of an empty list box is changed, it will not show up, or will flicker.
Adding an item to the list box halts this behavior.

Edit: This explains why I couldn't simulate a grayed out background in a list box yesterday. The list was empty.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 28, 2020, 04:20:40 PM
I implemented your changes and the problem persists.
You should be able to observe a focus loss after an item is selected. I'm seeing this in several projects that don't involve the Ctx control.
On these windows it may be difficult to see since the focus trace line isn't visible on a list box item.

1. I select an item in the list box.
2. I press tab.
3. I notice I cannot select another item by pressing the arrow keys, or by rotating the mouse wheel. I notice that the tab control did not receive focus.
4. I press tab.
5. Focus is returned to the list box, as I can now do what I described in step 3.

This may be trivial for mouse users who click on everything, but for keyboard users this is weird.
I haven't created a test project but based on the sequence of steps in your post it makes sense that in #3 you cannot select another item by pressing arrow keys, etc because the focus would have already left the listbox control when you pressed the TAB key in step #2.

#1. Listbox item gets focus because you either selected it by code or by clicking on it.
#2. Pressing TAB will move the focus from the Listbox to whatever the next control is in the tab order.
#3. The Lisbox now does not have focus so you can't change items via keyboard. You mention tab control - you have a TabControl in your project? That wasn't in the sample project that you posted earlier.
#4. Pressing TAB probably moved the control back to the Listbox again (most likely from your PictureBox to the Listbox).
#5. Listbox has focus so you can change items via arrow keys.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Paul Squires on June 28, 2020, 04:21:30 PM
It appears that when the back color of an empty list box is changed, it will not show up, or will flicker.
Adding an item to the list box halts this behavior.
Thanks - I have added this to my to do list to check into.
Title: Re: WinFBE Suite 2.1.7 (May 31, 2020)
Post by: Bumblebee on June 29, 2020, 07:35:47 AM
I implemented your changes and the problem persists.
You should be able to observe a focus loss after an item is selected. I'm seeing this in several projects that don't involve the Ctx control.
On these windows it may be difficult to see since the focus trace line isn't visible on a list box item.

1. I select an item in the list box.
2. I press tab.
3. I notice I cannot select another item by pressing the arrow keys, or by rotating the mouse wheel. I notice that the tab control did not receive focus.
4. I press tab.
5. Focus is returned to the list box, as I can now do what I described in step 3.

This may be trivial for mouse users who click on everything, but for keyboard users this is weird.
I haven't created a test project but based on the sequence of steps in your post it makes sense that in #3 you cannot select another item by pressing arrow keys, etc because the focus would have already left the listbox control when you pressed the TAB key in step #2.

#1. Listbox item gets focus because you either selected it by code or by clicking on it.
#2. Pressing TAB will move the focus from the Listbox to whatever the next control is in the tab order.
#3. The Lisbox now does not have focus so you can't change items via keyboard. You mention tab control - you have a TabControl in your project? That wasn't in the sample project that you posted earlier.
#4. Pressing TAB probably moved the control back to the Listbox again (most likely from your PictureBox to the Listbox).
#5. Listbox has focus so you can change items via arrow keys.
I added a tab control, but it doesn't receive focus. I don't know if that is an issue.
If I create a form with a list box, text box and tab control, focus will not jump to the tab control.

On the project I submitted, the focus should never leave the list box. I'm assuming it is going to the image, and not the label.
The issue is similar that of the picture box control in Visual Basic. If enabled is true, a picture box will take the focus when tab is pressed.

See the attached project for another focus issue. Description is in the executable file.