WinFBE Suite 2.1.7 (May 31, 2020)

[Paul Squires]

Hi Ray - you can disable that feature in the editor settings.

[SeaVipe]

:0)

[raymw]

Ok Paul, got it - disable character auto complete. thanks

[Paul Squires]

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.

[Paul Squires]

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.

[Paul Squires]

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.

[philbar]

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.

[Bumblebee]

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.

[Bumblebee]

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.

[José Roca]

> When I disable a list box, the background is not greyed out.

This is Windows normal behaviour.

[Paul Squires]

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

[Paul Squires]

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 Expand


''
''
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


[Bumblebee]

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.

[Bumblebee]

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.

[Paul Squires]

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.