Announcment: RC2 for the upcoming Version 1.2.

[exdatis]

Windows 7 ultimate 32 bit, openSuSe 13.1 32bit Gnome, Lazarus 1.2.RC2 works perfect.
Regards!

[georgebou]

I have been working with RC2 for over a month and it works fine.

However an RC3 wouldn't be a problem.

[otoien]

Any chance that someone could review the vertical scrolling methods used in this great IDE? Vertical scrolling does not work in the editor with the track point on my Lenovo Compact Bluetooth keyboard, opposed to the one on my T440p, and with scroll whell on a mouse. It works in all other applications except Notepad++ and Chrome above version 31 (They introduced new minimalist scroll bars in v. 32). I understand there are also issues in Chrome with USB version of that keyboard. The scrolling mouse cursor shows up in both cases but is different. The one on the Bluetooth keyboard will scroll any window below the cursor (and the scrolling mouse cursor has some vertical lines added to it), while the one on the computer requires a window be the selected to scroll. This is with "Lenovo preferred scrolling method" turned on which should basically be the same  as result mode on a mouse. Some writings on the Chrome support pages could indicate that there is a problem with the  program requiring the name of the window to scroll, but not getting it.

The two finger vertical scroll on the pad of the computer also does not work, but in this case the scrolling mouse cursor is similar to the one with the computer's trackpad that work, so this could be a separate issue. Horizontal scroll works with any method. I also tested the scrolling example, and the same vertical scroll problem is present there. This problem is not unique to 1.2 RC2, the same happens in earlier versions, tested v. 1.0.14.

[BigChimp]

@otoien: please open a bug report with exact details about your system and the behaviour you see.

You could also try with current development/trunk version of Lazarus to see if scrolling behaviour has improved. If so, a backport to the Laz 1.2.x series could probably be made fairly easily.

Thanks.

[Martin_fr]

About scrolling:
related to: http://bugs.freepascal.org/view.php?id=25209

Other IDE windows do scroll? (e.g. Object Inspector?)

For the bug report, not here on the forum, please put some debugln into

procedure TCustomSynEdit.WMMouseWheel(var Message: TLMMouseEvent);
(file synedit.pp / line 7163)

And capture see output (log file --debug-log=)
See if it is called, and what params are passed

   debugln(['WHEEL ',Message.X,' ',Message.Y,'  ',Message.WheelDelta]);

[otoien]

Thanks for the responses both of you, and please bear over with me being a bit slow here, things are pretty new to me, and I am trying to find my way around things.

As a start I can confirm that the scrolling issue also affects Object Inspector, Code Explorer and windows like the Debug Output, but not surprising it does not affect the file dialogs as Windows probably is responsible for those. I assume this means the problem is not limited to SynEdit? One little thing is that when first clicking a window and trying vertical scroll I may occasionally get a scrolling response on the very first attempt (may happen with both the bluetooth keyboards trackpoint and two-finger scroll with two-finger scroll on the Thinkpad T440p, but on the next attempts to scroll, it remains unresponsive. So perhaps it is a timing issue with respect to catching the mouse messages? I do use another compiler IDE, mikroPascal for dsPIC, that as far as I know is also based on SynEdit, but written in Delphi 2007, and I have no scrolling issues in that compiler.

I am not sure that  the bug report referenced by you Martin is the same as the bluetooth keyboards trackpoint scrolling, but it may well be the case for the two-finger scroll on my T440p which seems different, and  that is a Synaptics trackpad. While the bluetooth keyboard trackpoint, vertical scroll does not work in Notepad++, the two finger scroll on the computer does. There are two different issues on the Chrome pages, the one related to the bluetooth keyboard is this one: http://code.google.com/p/chromium/issues/detail?id=335941.

I was able to register on the bugtracker page, but I did not want to enter the bugreport before I have all the information, and I am not sure I got the debug output to work with RC2. (I found a proper place to insert the line at the end of the TCustomSynEdit.WMMouseWheel procdure ). Where is the log file supposed to be written and how is it named? (The info in the debug output windows does not seem to output any related information.)  I am working on learning how to download and install the trunk/SVN version; my computer is so new that I have not configured much in Lazarus yet, so I might just as well install it over RC2? Would the patch mentioned in the bugreport already have been included in the SVN version or do I have to learn how to install that one?

[BigChimp]

Generally:
If a bug report is marked as closed, an included patch is probably included. Probably because the developers can choose to implement another solution or not, so you'd have to go by the comments in the report.
Also, the revision number of the change is marked in closed bug reports; you can track exactly what was implemented using subversion tools, e.g. example for revision 44287:
http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&root=lazarus&revision=44287

If the report is still open, a patch has probably not been included.

[Martin_fr]

If it happens in all windows, (except the dialogs, which indeed a handled by windows), then you do not need to add the line to SynEdit.

Instead you should apply the  patch that is attached to the issue, and see if that helps.

Not sure what patch command best to use (I use TortoiseSvn, but you might need an svn checkout for that to work). There is a "patch.exe" in the fpc binaries folder, and IIRC the wiki has some article on using patches.
(If it crashes, use notepad++ to change the line-endings.)

should be
cd lazarus
patch -p0 < synaptics_new.patch

[otoien]

Thanks Martin,
I tried tried ToroiseSVN, and not surprisingly it reported it was "not a working copy".
I tried the command line patch after copying patch.exe to the lazarus window, it just opened up a black window with no report. Nothing appeared to have been added to win32callback.inc. Not surprising as the svn listed in the patch is lower than the one in RC2, so line numbers might have differed for the patch to work. Inspecting the patch in TortoiseSVN, it marked pretty clearly where the patch was to go, so I patched win32callback.inc manually by editing the code.

After Lazarus rebuild, as suspected, the patch fixed the problem with the two-finger scroll on the Thinkpad T440p touchpad in the editor and object inspector etc, but not the problem with vertical scroll with the Lenovo Compact Bluetooth keyboard.  (The scroll bar example still does not work, but even before the patch, it would also not work with my bluetooth mouse, only the trackpoint on the T440p. The IDE does work with the Bluetooth mouse, so this might be a problem with the example).

So I assume I should file a separate bug report for the Bluetooth keyboard, and perhaps one need to look into whatever solution the Chrome project find to that (see my last reference above). Yesterday there was one report that it worked in the latest version of Chrome after another fix, but I have not tested that as I have disabled Google update beyond v. 31 until I have a god confirmation that it is fixed.

[Martin_fr]

Yes probably best to open another bug report, and mention the findings that where made until now. (Also that it is not fixed by the patch)

It will probably someone other than me, who will look at it. I picked up this thread because the editor/synedit was mentioned. SynEdit is my domain.

In any case, it may be useful to see what happens in wint32callback.

Where you added the code:

Code: [Select]

          GetClassNameA(SynapticsWindow, SynapticsClassName, 50);
          if SynapticsClassName = 'SynTrackCursorWindowClass' then
            TargetWindow := Window;

Add the following:

Code: [Select]

          GetClassNameA(SynapticsWindow, SynapticsClassName, 50);

  debugln(['WHEEL ', SynapticsClassName,
                '  W=', dbgs(Window),
                '  TW=', dbgs(TargetWindow),
                '  MWRedir=', dbgs(InMouseWheelRedirection)
]);

          if SynapticsClassName = 'SynTrackCursorWindowClass' then
            TargetWindow := Window;

-----------
You can also *Always* (without condition) do
            TargetWindow := Window;

This will disable the "follow mouse" behaviour, that is scroll will apply to the focused window, instead of the window below the mouse.

[otoien]

Thanks a lot, removing the condition gave me the vertical scrolling as you predicted, I am very happy, as I have become very addicted to using the trackpoint for scrolling, and it is very efficient and saves a lot of repetitive movements!

The interesting thing is that it still is able to scroll even if the window is not selected, i .e  the window is just under the mouse cursor. Another interesting thing is that the way the selected "Thinkpad preferred scrolling" in the Keyboard setup is supposed to work is to only act on the selected window, not the one under the cursor, at least this is the way it worked when I initially tested the keyboard on a WinXP system. But on Win7 it acts on window under the mouse cursor. Perhaps there is a bug in the driver under win7 that confuses certain applications?

The scroll example still do not work though, either with the bluetooth keyboard trackpoint or the mouse scroll wheel, only with the trackpoint on the computer itself. Might be a different problem perhaps.

I have not been able to make the log file output work. Before rebuild, I turned on the debugging option under configure build Lazarus, and as instructed in the wiki FAQ, "How can I use a Log-file for debugging the IDE itself", I run it with parameters --debug-log=lazarusdebuglog.txt in the shortcut or activated from the command line, but no logfile  seen in the lazarus folder.

Should I still do the bug report or would just adding a comment about the findings to the current one be more appropriate?

[Martin_fr]

There is a bug with the logfile. (will be fixed in next release)

Specify a full qualified name --debuglog=C:\foo\bar.txt

[otoien]

Still no debug log file. Rebuilt lazarus with the debug option on in the configure build lazarus.
Then started lazarus with the command line:
lazarus --debuglog=C:\lazarus\debuglog.txt
I am still running 1.2 RC2. Anything else I am missing? I see a number of debug statements inserted in the code elsewhere. It occurs to me that the file would become big very quickly when catching mouse messages?

[Martin_fr]

Sorry this was my fault, I missed a dash

--debug-log=c:\log.txt

The log will grow yes, but it will be reasonable, if you only use it for a minute or two.

[otoien]

Thanks, got it working now, I  have one log with (scroll not working) and without (scroll working) the conditional statement. Should I now create a separate bug report as initially planned to upload those logs?