PlanetSquires Forums

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: WinFBE 2.1.3 - Minor issues.  (Read 512 times)

SeaVipe

  • Senior Member
  • ***
  • Posts: 365
  • Windows 10
WinFBE 2.1.3 - Minor issues.
« on: April 23, 2020, 03:17:46 PM »

Hi Paul,
-Visual Designer. Picture controls are not displaying the attached image from session to session without making a minor edit to the control - that change will display the attached graphic in the designer (like adding a ToolTip).
-WinFBE is no longer starting up in the position or size from the last session.
-StatusBar. All colours were set to default, though my project has 2 Panels with unique colouring. I reestablished the unique colouring and so far they are correct from session to session. When the StatusBar editor is first opened in a new session, the colours appear as default colours but a mouse-over sets them to the user defined colours and they compile and run correctly (This has been the case for a number of releases).
Logged
Clive Richey
*“You Either Have To Be Part Of The Solution, Or You’re Going To Be Part The Problem.” Eldridge Cleaver.
#StaySafe, Always  Keep A Safe #SocialDistance, #WashYourHands Often and please, #StayHome!

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #1 on: April 23, 2020, 06:04:12 PM »

Hi Paul,
-Visual Designer. Picture controls are not displaying the attached image from session to session without making a minor edit to the control - that change will display the attached graphic in the designer (like adding a ToolTip).
Thanks. I will look into this and hopefully recreate the prblem and fix it.

Quote
-WinFBE is no longer starting up in the position or size from the last session.
Do you mean WinFBE itself or just the visual designer/toolbox window. I did make changes to the toolbox window to try to help it position correctly on dual monitor systems. If you then subsequently move back tot a single monitor setup then the dialog resets to something much smaller on the main screen.

Quote
-StatusBar. All colours were set to default, though my project has 2 Panels with unique colouring. I reestablished the unique colouring and so far they are correct from session to session. When the StatusBar editor is first opened in a new session, the colours appear as default colours but a mouse-over sets them to the user defined colours and they compile and run correctly (This has been the case for a number of releases).
I remember this being discussed before and for the life of me I thought that I had fixed whatever was wrong. Lol. I will look again.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

SeaVipe

  • Senior Member
  • ***
  • Posts: 365
  • Windows 10
Re: WinFBE 2.1.3 - Minor issues.
« Reply #2 on: April 23, 2020, 06:51:28 PM »

Quote
Do you mean WinFBE itself or just the visual designer/toolbox window. I did make changes to the toolbox window to try to help it position correctly on dual monitor systems. If you then subsequently move back tot a single monitor setup then the dialog resets to something much smaller on the main screen.
Paul, I've been doing some experimenting and it appears as though WinFBE gets the Left okay but not the last session's Top or Height IF the last session's Top and Height were set automatically. By 'automatically' I mean by dragging the top of the WinFBE window to the screen top and letting Windows 10 snap to top = 0 and bottom = the top of the Windows Taskbar. WinFBE will return to the Top and Height settings from the last session providing they were set manually and not 'automatically' set. I didn't realize that was happening prior to my earlier post.
My monitor setup does not change - a creature of habit.
Logged
Clive Richey
*“You Either Have To Be Part Of The Solution, Or You’re Going To Be Part The Problem.” Eldridge Cleaver.
#StaySafe, Always  Keep A Safe #SocialDistance, #WashYourHands Often and please, #StayHome!

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #3 on: April 25, 2020, 12:04:18 PM »

Quote
Do you mean WinFBE itself or just the visual designer/toolbox window. I did make changes to the toolbox window to try to help it position correctly on dual monitor systems. If you then subsequently move back tot a single monitor setup then the dialog resets to something much smaller on the main screen.
Paul, I've been doing some experimenting and it appears as though WinFBE gets the Left okay but not the last session's Top or Height IF the last session's Top and Height were set automatically. By 'automatically' I mean by dragging the top of the WinFBE window to the screen top and letting Windows 10 snap to top = 0 and bottom = the top of the Windows Taskbar. WinFBE will return to the Top and Height settings from the last session providing they were set manually and not 'automatically' set. I didn't realize that was happening prior to my earlier post.
My monitor setup does not change - a creature of habit.

This is an interesting situation. It is easily reproduced by startign WinFBE and pressing WinKey+LeftArrow to "Aero snap" the editor to the elft side of the screen and take up half the screen width. Close WinFBE and then restart it. You'd expect WinFBE to be positioned covering the left half of the screen. This is not the case as the editor just shows in its Normal state.

I did some research and it seems like GetWindowPlacement and SetWindowPlacement does not honor the snap. Here is a link to a Stack Overflow question affirming the same:  https://stackoverflow.com/questions/5673242/getwindowplacement-gives-the-incorrect-window-position

Not sure how to "fix" this yet as moving away from GetWindowPlacement may have problems with dealing multimonitor setups.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #4 on: April 25, 2020, 12:04:52 PM »

-StatusBar. All colours were set to default, though my project has 2 Panels with unique colouring. I reestablished the unique colouring and so far they are correct from session to session. When the StatusBar editor is first opened in a new session, the colours appear as default colours but a mouse-over sets them to the user defined colours and they compile and run correctly (This has been the case for a number of releases).

Thanks - I have this one fixed now.
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #5 on: April 25, 2020, 12:20:42 PM »

Quote
Do you mean WinFBE itself or just the visual designer/toolbox window. I did make changes to the toolbox window to try to help it position correctly on dual monitor systems. If you then subsequently move back tot a single monitor setup then the dialog resets to something much smaller on the main screen.
Paul, I've been doing some experimenting and it appears as though WinFBE gets the Left okay but not the last session's Top or Height IF the last session's Top and Height were set automatically. By 'automatically' I mean by dragging the top of the WinFBE window to the screen top and letting Windows 10 snap to top = 0 and bottom = the top of the Windows Taskbar. WinFBE will return to the Top and Height settings from the last session providing they were set manually and not 'automatically' set. I didn't realize that was happening prior to my earlier post.
My monitor setup does not change - a creature of habit.

This is an interesting situation. It is easily reproduced by startign WinFBE and pressing WinKey+LeftArrow to "Aero snap" the editor to the elft side of the screen and take up half the screen width. Close WinFBE and then restart it. You'd expect WinFBE to be positioned covering the left half of the screen. This is not the case as the editor just shows in its Normal state.

I did some research and it seems like GetWindowPlacement and SetWindowPlacement does not honor the snap. Here is a link to a Stack Overflow question affirming the same:  https://stackoverflow.com/questions/5673242/getwindowplacement-gives-the-incorrect-window-position

Not sure how to "fix" this yet as moving away from GetWindowPlacement may have problems with dealing multimonitor setups.


Okay, I added a call to GetWindowRect and then only update the GetWindowPlacement values should the values differ. I will keep this code in for the next update and then pay attention to see if anyone reports any issues with it. In my few tests, it does seem to correct the reported issue.

Code: [Select]
   ' Determine the current editor positioning
   Dim WinPla As WINDOWPLACEMENT
   WinPla.Length = Sizeof(WinPla)
   GetWindowPlacement( HWND_FRMMAIN, @WinPla )
   With this
      .StartupLeft   = WinPla.rcNormalPosition.Left
      .StartupTop    = WinPla.rcNormalPosition.Top
      .StartupRight  = WinPla.rcNormalPosition.Right
      .StartupBottom = WinPla.rcNormalPosition.Bottom
      .StartupMaximized = Iif( WinPla.showCmd = SW_MAXIMIZE, True, False )
   End With
   
   dim as RECT rc
   GetWindowRect( HWND_FRMMAIN, @rc )
   if this.StartupLeft <> rc.Left then this.StartupLeft = rc.Left
   if this.StartupTop <> rc.Top then this.StartupTop = rc.Top
   if this.StartupRight <> rc.Right then this.StartupRight = rc.Right
   if this.StartupBottom <> rc.Bottom then this.StartupBottom = rc.Bottom
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #6 on: April 25, 2020, 03:00:14 PM »

-Visual Designer. Picture controls are not displaying the attached image from session to session without making a minor edit to the control - that change will display the attached graphic in the designer (like adding a ToolTip).

Got this one fixed. Was a bit hard to track down
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

SeaVipe

  • Senior Member
  • ***
  • Posts: 365
  • Windows 10
Re: WinFBE 2.1.3 - Minor issues Part Du.
« Reply #7 on: April 25, 2020, 03:47:21 PM »

Thanks, Paul.
Here is one that I can't repeat without any reliability: ListView. The text of a single row will sometimes display as a single (?) character from another language (perhaps Chinese or a similar language). Sometimes just scrolling the ListView V or H will clear the character and replace it with the correct English text, but not always.
I thought that it had something to do with the length of the text but I couldn't repeat the problem with any consistency. Changing the contents of the text didn't make any difference either.
Logged
Clive Richey
*“You Either Have To Be Part Of The Solution, Or You’re Going To Be Part The Problem.” Eldridge Cleaver.
#StaySafe, Always  Keep A Safe #SocialDistance, #WashYourHands Often and please, #StayHome!

Paul Squires

  • Administrator
  • Guru Member
  • *****
  • Posts: 9301
  • Windows 10
    • PlanetSquires Software
Re: WinFBE 2.1.3 - Minor issues.
« Reply #8 on: April 25, 2020, 06:21:33 PM »

How are you populating the listview? I mean, where is the data coming from? Could it be that the incoming data has some weird characters in it???
Logged
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

SeaVipe

  • Senior Member
  • ***
  • Posts: 365
  • Windows 10
Re: WinFBE 2.1.3 - Minor issues.
« Reply #9 on: April 25, 2020, 07:16:44 PM »

One is populated from a Type (part of the structure of a disk file): Body( 1 To 30 ) As String * 500. Initial text is loaded from a file operation and subsequent changes to the ListView would be from an edited TextBox (see image for properties of the TextBox).
the other is from a different Type: Declare Function get_body ( ByVal in_str As String ) As String - the screenshot from my previous post. This is SMS/MMS plain text from a capture utility on my mobile.
Both are simple Strings and neither are converted from a String to any other string type.
Logged
Clive Richey
*“You Either Have To Be Part Of The Solution, Or You’re Going To Be Part The Problem.” Eldridge Cleaver.
#StaySafe, Always  Keep A Safe #SocialDistance, #WashYourHands Often and please, #StayHome!