FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

User projects written in or related to FreeBASIC.
SARG
Posts: 794
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby SARG » Jul 29, 2017 16:50

Hi Sancho2,
Thanks for your help.

sancho2 wrote:I am definitely using scaling here on Win 10. I disabled it for fbDebugger as per St. W. but the problem still exists.
I will try to shut of scaling completely, if I can find the setting, and report back.
As I got no change :-(

sancho2 wrote:I downloaded and compiled that settings version you linked Sarg. It doesn't print anything to the console. Did I miss something.
Maybe you didn't select Settings.
I have uploaded a new version http://users.freebasic-portal.de/sarg/F ... ttings.bas
Now the values are displayed in a message box. Don't forget to click on the settings button ;-)

About the shortcut.
You can't select and expand a variable from the code source window. The shortcut works but with the element already selected in proc/var tree.
In your example I guess that X is selected in this tree (left panel). You can try again selecting the main proc line in the tree and then using the shortcut. The expand was not with X.

The only time (that I have found) where there is no response is when you click twice on 'proc/var' button, title surrounded by a dashed line.
In this case the shortcut doesn't work, No notification sent or is not handled.
Unless I miss also something :-)
St_W
Posts: 932
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby St_W » Jul 29, 2017 17:09

SARG wrote:
sancho2 wrote:I am definitely using scaling here on Win 10. I disabled it for fbDebugger as per St. W. but the problem still exists.
I will try to shut of scaling completely, if I can find the setting, and report back.
As I got no change :-(

I see, so HiDPI scaling doesn't seem to be the problem. Probably would have been a bit too obvious ... :-|
sancho2
Posts: 513
Joined: May 17, 2015 6:41

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby sancho2 » Jul 29, 2017 23:24

I definitely hit settings button.
Its no matter though as the message box version works and here are the results:
baseunits=14000A
right=10 bottom=20
scale x y = 2 2

I won't be back at the computer for 24 hours. I hope this helps.
Kuan Hsu
Posts: 225
Joined: Sep 16, 2007 15:12
Location: Taiwan

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby Kuan Hsu » Jul 30, 2017 1:52

Dear SARG:
I've test the parser of my poseidonFB IDE( use your source, 14,193 lines / one file! ), but I found the parse result isn't correct.

I try to find where issue is, I found at Line 2269:

Code: Select all

           Case IDBUTFILE
                treat_file("?_NO$FILE_$?) 'hope that nobody uses a such name ;-)
                SetFocus(windmain)

The parameter of treat_file() isn't a string( not complete string), but it compile pass?
SARG
Posts: 794
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby SARG » Jul 30, 2017 8:43

Kuan Hsu wrote:Dear SARG:
I've test the parser of my poseidonFB IDE( use your source, 14,193 lines / one file! ), but I found the parse result isn't correct.

I try to find where issue is, I found at Line 2269:

Code: Select all

           Case IDBUTFILE
                treat_file("?_NO$FILE_$?) 'hope that nobody uses a such name ;-)
                SetFocus(windmain)

The parameter of treat_file() isn't a string( not complete string), but it compile pass?

Dear Kuan Hsu
Just because there is an ASCII character converting (from your side) : the real string is "£$_NO$FILE_$£".
In detail if display not right : the 2 first characters are the symbol of the English pound followed by a dollar. The 2 last ones dollar and pound. And the converting removes the last double quotation mark.......
SARG
Posts: 794
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby SARG » Jul 30, 2017 9:53

Thanks to the values provided by Sancho, the issue (bad display in some dialog boxes) reported by him and AGS is (should be) now fixed.

In dialog boxes the way to calculate dimensions use integers but "singles" must be used as sometimes due to screen size or anything else the values are decimal numbers...... So I have replaced integer by single everywhere it was necessary.

New test version : http://users.freebasic-portal.de/sarg/F ... ttings.bas

@Sancho2 you should get "scale x y = 2.5 2.5" and obviously a good display.
AGS
Posts: 1281
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby AGS » Jul 30, 2017 22:35

@SARG

Size of the screen is 1680 x 1050.

Values for converting map/pixel reads:

Code: Select all

baseunits = 1400A
right = 10 bottom = 20
scale x y = 2.5 2.5


The buttons look fine now.

A couple of pictures to show what the screens look like now

Image
Image

The text used in fb_Groups (also used in settings window) looked a lot smaller in the new version though.
Code used to create a group looks like

Code: Select all

fb_Group("Customize shortcuts : select a combination, use ""A"" button to check and apply, ""Del"" key To delete",hwnd,2003,6*scalex,2*scaley,252*scalex,20*scaley)


I looked into fb_group and found that it is the only place where ANSI_VAR_FONT is used

Code: Select all

SendMessage(A,WM_SETFONT,Cast(WPARAM,GetStockObject(ANSI_VAR_FONT)),0) ''SYSTEM_FONT DEFAULT_GUI_FONT


Which appears to be the reason why the text is so small. An easy fix was to change ANSI_VAR_FONT to DEFAULT_GUI_FONT.
After changing ANSI_VAR_FONT to DEFAULT_GUI_FONT this is what I get
Image

Which looks fine to me. So the change from DEFAULT_GUI_FONT to ANSI_VAR_FONT actually made things worse for me.
Changing ANSI_VAR_FONT back to what it was (DEFAULT_GUI_FONT) fixed the problem.
sancho2
Posts: 513
Joined: May 17, 2015 6:41

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby sancho2 » Jul 31, 2017 1:15

Yes the scale value are now 2.5 2.5 and the buttons are properly formatted.
Nice debugging Sarg.
AGS
Posts: 1281
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby AGS » Jul 31, 2017 3:11

@SARG

I tried the version of fbdebugger that shows the expand window when hovering. And it's great to use. I did find that using ctrl was not what I wanted. It took me very little time to change the code so it doesn't use ctrl. I think that turning the use of ctrl into an option would not be too hard.

This use of hovering in combination with a key (ctrl or other) can, however, be very useful. An example.

When using a pointer - intensive application the initial show/expand variable gets me a window where I can (when hovering a node) either:
--> replace current
--> open new window
--> .... (other buttons)

replace current is the one I'd want when hovering. But alas, in this window no hovering behaviour. Sometimes I'd want to open a new window when hovering. ctrl - hover could be used for that. Using both hover and ctrl - hover (shift - hover, alt - hover, ... - hover) I could control what happens when hovering. Which is very useful.

It should be possible for the user to select what happens when hovering with- and without a key (ctrol or shift or alt or ...).
Perhaps it would be possible to bind hover - actions to whatever is available in a certain window. Much like is done already for shortcut keys.

The action associated with hovering is a context - dependent action. In window x it would be possible to bind hovering to the action associated with a button or the action associated with a menu item.

The user could be able to decide what happens when hovering (either with- or without pressing ctrl or some other key). And I'd like to be able to set this hovering behaviour not just on the proc/var window of the gui.
From a practical point of view adding hovering functionality to at least the tree in the shwexp_box (besides the tree in proc/vars) would be most useful.

I found that here is no possibility to set a shortcut key for replace current. I am guessing that settings shortcuts is only possible for a limited number of gui elements. It would be nice if it would be possible to get shortcut keys for the buttons in a shwexp_box (I'd prefer to use hovering but other users might prefer using keys).

I found a 'bug' (I think).

The combo box at the top of the window you get when choosing tools->settings contains a duplicate entry. the entry is called show/expand variable. You cannot set the same shortcut key for both entries which could mean that the two entries refer to different elements of the gui.
SARG
Posts: 794
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby SARG » Aug 02, 2017 17:36

AGS wrote:Changing ANSI_VAR_FONT back to what it was (DEFAULT_GUI_FONT) fixed the problem.
You are right. I made several tests (as you can see on the line different strings) and I forgot to reset the old parameter.... Fixed


AGS wrote:@SARG

I tried the version of fbdebugger that shows the expand window when hovering. And it's great to use. I did find that using ctrl was not what I wanted. It took me very little time to change the code so it doesn't use ctrl. I think that turning the use of ctrl into an option would not be too hard.

This use of hovering in combination with a key (ctrl or other) can, however, be very useful. An example.

When using a pointer - intensive application the initial show/expand variable gets me a window where I can (when hovering a node) either:
--> replace current
--> open new window
--> .... (other buttons)

replace current is the one I'd want when hovering. But alas, in this window no hovering behaviour. Sometimes I'd want to open a new window when hovering. ctrl - hover could be used for that. Using both hover and ctrl - hover (shift - hover, alt - hover, ... - hover) I could control what happens when hovering. Which is very useful.

It should be possible for the user to select what happens when hovering with- and without a key (ctrol or shift or alt or ...).
Perhaps it would be possible to bind hover - actions to whatever is available in a certain window. Much like is done already for shortcut keys.

The action associated with hovering is a context - dependent action. In window x it would be possible to bind hovering to the action associated with a button or the action associated with a menu item.

The user could be able to decide what happens when hovering (either with- or without pressing ctrl or some other key). And I'd like to be able to set this hovering behaviour not just on the proc/var window of the gui.
From a practical point of view adding hovering functionality to at least the tree in the shwexp_box (besides the tree in proc/vars) would be most useful.

I found that here is no possibility to set a shortcut key for replace current. I am guessing that settings shortcuts is only possible for a limited number of gui elements. It would be nice if it would be possible to get shortcut keys for the buttons in a shwexp_box (I'd prefer to use hovering but other users might prefer using keys).

Done what you want ;-) http://users.freebasic-portal.de/sarg/FBdebugger.bas and the exe (32bit only) http://users.freebasic-portal.de/sarg/FBdebugger.exe

There is a new option in settings allowing the use of CTRL key (or not) when hovering on the proc/var tree to open the show/expand window.
This choice is saved/restored when exiting/starting Fbdebugger.

Now inside a show/expand window hovering on an element either opens a new show/expand window (with or without CTRL key depending of settings) or just replaces the current one (with SHIFT key).
To avoid unwanted opening of show/expand windows the cursor (mouse) is automatically moved on the right side of the window. Otherwise multiple occurences are created.....

I hope it's clear :-)


AGS wrote:I found a 'bug' (I think).
The combo box at the top of the window you get when choosing tools->settings contains a duplicate entry. the entry is called show/expand variable. You cannot set the same shortcut key for both entries which could mean that the two entries refer to different elements of the gui.
I have not yet look at that but as there is 2 calls to show/expand (proc/var tree and watched tree) it could be a problem. I'll dig that point later.


I found an issue (fbdebugger crashs) when displaying show/expand with an udt containing a field which is a dynamic array. For now it does not crash anymore and it just displays "[Dynamic array can't display value]". I'll fix that later.
AGS
Posts: 1281
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby AGS » Aug 06, 2017 11:12

The shift - hover does not seem to work. I always get a new window (replace current is never used).

The movement of the mouse cursor to the right is a solution for the problem with infotip delay times.

Which I think is why you suggested adding the ctrl - hover in the first place (to prevent users from accidentally getting pop ups).

According to microsoft the following values can be set (hover times related to infotips)

Code: Select all

Initial. The time the pointer must remain stationary for the tip to appear. The default time is 0.5 seconds.
Reshow. The time the pointer must remain stationary as the pointer moves from one target to another. The default time is 0.1 seconds.
Removal. The time after which the tip is automatically removed. The default time is 5 seconds.


I could not find out where to set the above values. I tried setting them using the tooltip associated with the tree but to no avail.

Moving the mouse all the way to the right after hovering is a bit too much. How about moving it a little bit to the left of the last item hovered? Just a touch to the left.
SARG
Posts: 794
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby SARG » Aug 09, 2017 14:13

Small access to internet until the end of week and no pc.....
SHIFT key is only working in show/expand window.

For what you suggested I'll see that later.
Not sure tooltips parameters could be changed for standard controls.
AGS
Posts: 1281
Joined: Sep 25, 2007 0:26
Location: the Netherlands

Re: FB debugger : 2.91 32/64 BIT ..... (Aug 20th, 2016)

Postby AGS » Aug 13, 2017 0:26

I've looked around on the net for solutions to setting the infotip hovering time. I could not find anything other than workarounds.
I think a possible workaround to get a solid hover time without having to set a timer somewhere in code (to 'emulate' hover time) is by using
TrackMouseEvent.

Code: Select all

  dim tme as TRACKMOUSEEVENT

  tme.cbSize = sizeof(TRACKMOUSEEVENT)
  tme.dwFlags = TME_HOVER
  tme.hwndTrack = hwnd   ''set hwnd to tree control
  tme.dwHoverTime = HOVER_DEFAULT '' same as hovertime for tooltip
  if (TrackMouseEvent (@tme) = 0 ) then '' problem!!!!


Hovering could work using a combination of WM_HOVER and WM_NOTIFICATION.

The user moves the mouse on top of an item in the tree.
The WM_NOTIFICATION event fires (INFOTIP) and the debugger does nothing but 'remember' which item the mouse is pointing at.

Instead of

Code: Select all

   SendMessage(tviewvar,TVM_SELECTITEM,TVGN_CARET,Cast(lparam,pnotify2->hitem))''change selection


you'd get

Code: Select all

  var tree_item = Cast(lparam,pnotify2->hitem)) ''' save selected tree item


Then the WM_MOUSEHOVER event fires due to hovering on the tree.

Code: Select all

  case WM_MOUSEHOVER:
     SendMessage(tviewvar,TVM_SELECTITEM,TVGN_CARET,tree_item)''change selection     


I think the timing should be no problem(eg WM_MOUSEHOVER and WM_NOTIFICATION relating to the same HTREEITEM).

I don't really like these kind of workarounds so here is another method to get the timing of hovering working.

You can use TrackMouseEvent to track hovering of the mouse.
If the mouse hovers for a set amount of time on the treeview a test to see whether there is an item (and which one) beneath the mouse cursor would be enough to figure out which treeitem the mouse is hovering.

The WM_MOUSEHOVER gives some info as to where the hover occured

Code: Select all

case WM_MOUSEHOVER:
  var xPos = GET_X_LPARAM(lParam)
  var yPos = GET_Y_LPARAM(lParam)


Knowing xPos and yPos it should be possible to perform a TVM_HITTEST to get the item below the mouse
(I've seen some code in the debugger that does just that).

I think TrackMouseEvent could work out far better than the whole INFOTIP stuff.

After the WM_MOUSEHOVER another call to TrackMouseEvent is needed to start tracking the mouse again.

The idea to use TrackMouseEvent I got from.... GTK+. The GTK+ developers use TrackMouseEvent on the win32 platform.

Return to “Projects”

Who is online

Users browsing this forum: Baidu [Spider] and 3 guests