Re: [Lazarus] Showing selection on drawing under Cocoa

2019-10-16 Thread Dmitry Boyarintsev via lazarus
On Wed, Oct 16, 2019 at 4:33 PM C Western via lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> Am I missing something? How does the Cocoa toolkit expect this to be done?
>
I'm see 3 ways of doing that.
1) you just invalidate the needed rectangle lines (or the entire selected
area) and do xor drawing  on paint event.

2) you might want to try to play with "focusRing" settings of NSView. That
requires Cocoa level access to the view. Not cross platform, obviously.

3) instead of drawing into the view itself, you might want to create a
semi-transparent window or a control, to be at the top of the hierarchy.
and draw a focus as an overlay. Obviously you want this window or control
to ignore any keyboard or mouse events (not to interfere with underlying
controls).
The solution can be cross platform.

Approach #1 seems to be the easiest at this point.

thanks,
Dmitry
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] Showing selection on drawing under Cocoa

2019-10-16 Thread C Western via lazarus
Is there an easy way of indicating a selection on a plot in Cocoa? I 
have a plot that is relatively time consuming to plot (particularly 
under Cocoa), and I want to be able to indicate the area selected with a 
mouse. On other widget sets I can xor a rectangle and do this quickly in 
the mouse event handler, but this is not possible under Cocoa because 
you can only plot during a paint event, so I have to invalidate the 
selected area and redraw the entire plot just to show a selection.


Am I missing something? How does the Cocoa toolkit expect this to be done?

Colin

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] DBNavigator: why is the refresh button enabled only if the dataset is modifiable?

2019-10-16 Thread Luca Olivetti via lazarus

El 16/10/19 a les 19:49, Juha Manninen via lazarus ha escrit:

On Wed, Oct 16, 2019 at 6:11 PM Luca Olivetti via lazarus
 wrote:

In lcl/include/dbcustomnavigator.inc, method
TDBCustomNavigator.EditingChanged

CanModify:=Enabled and FDataLink.Active and FDataLink.DataSet.CanModify;
...
Buttons[nbRefresh].Enabled:=CanModify;


I don't know DBNavigator well. It has 2 sets of buttons, the "Buttons"
and then "FocusableButtons". What are those?
The same TDBCustomNavigator.EditingChanged method also has:
   FocusableButtons[nbRefresh].Enabled:=Enabled and FDataLink.Active
and not FDataLink.Editing;
Maybe the same conditions would apply to Buttons[nbRefresh] as well.


I don't know either, I just find it strange that the refresh button is 
disabled when it's most needed.

And even stranger that I didn't notice until today ;-)
Or maybe I did and forgot about it :-D

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] DBNavigator: why is the refresh button enabled only if the dataset is modifiable?

2019-10-16 Thread Juha Manninen via lazarus
On Wed, Oct 16, 2019 at 6:11 PM Luca Olivetti via lazarus
 wrote:
> In lcl/include/dbcustomnavigator.inc, method
> TDBCustomNavigator.EditingChanged
>
> CanModify:=Enabled and FDataLink.Active and FDataLink.DataSet.CanModify;
> ...
> Buttons[nbRefresh].Enabled:=CanModify;

I don't know DBNavigator well. It has 2 sets of buttons, the "Buttons"
and then "FocusableButtons". What are those?
The same TDBCustomNavigator.EditingChanged method also has:
  FocusableButtons[nbRefresh].Enabled:=Enabled and FDataLink.Active
and not FDataLink.Editing;
Maybe the same conditions would apply to Buttons[nbRefresh] as well.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Juha Manninen via lazarus
On Wed, Oct 16, 2019 at 7:18 PM Werner Pamler via lazarus
 wrote:
> Hmmh - I never thought about this, I always thought this is a "new
> feature" and should stay in trunk. ATM, I cannot focus on merging VTV to
> fixes. It isn't a show-stopper, isn't it?

Not a show-stopper.
If I remember right, it may prevent installing many versions of VTV
simultaneously but there are ways around it.
The System.Move change was not a show-stopper either because Lazarus
2.0.6 will be released with FPC 3.0.4, but it is convenient anyway for
people who want to use a different compiler.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Maxim Ganetsky via lazarus


16.10.2019 19:15, Werner Pamler via lazarus пишет:
> Am 16.10.2019 um 16:52 schrieb Juha Manninen via lazarus:
>> On Wed, Oct 16, 2019 at 4:41 PM Werner Pamler via lazarus
>>  wrote:
>>> I don't know what you are referring to, here. In r61814 I had added the
>>> "System" namespace here in VTV because fpc 3.2+ has a Move method in
>>> TCollection which conflicts with the old code.
>> r61814 in fixes branch seems to a merge from Michael's r60784 in trunk.
>> Your big rename commit r60132 in trunk would be useful, too, but I
>> guess difficult to merge.
> 
> 
> Hmmh - I never thought about this, I always thought this is a "new
> feature" and should stay in trunk. ATM, I cannot focus on merging VTV to
> fixes. It isn't a show-stopper, isn't it?

This should NOT be merged, because it introduced dotted unit names into
the wild and required major changes to translation system.

-- 
Best regards,
 Maxim Ganetsky  mailto:gan...@narod.ru
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Werner Pamler via lazarus

Am 16.10.2019 um 16:52 schrieb Juha Manninen via lazarus:

On Wed, Oct 16, 2019 at 4:41 PM Werner Pamler via lazarus
 wrote:

I don't know what you are referring to, here. In r61814 I had added the
"System" namespace here in VTV because fpc 3.2+ has a Move method in
TCollection which conflicts with the old code.

r61814 in fixes branch seems to a merge from Michael's r60784 in trunk.
Your big rename commit r60132 in trunk would be useful, too, but I
guess difficult to merge.



Hmmh - I never thought about this, I always thought this is a "new 
feature" and should stay in trunk. ATM, I cannot focus on merging VTV to 
fixes. It isn't a show-stopper, isn't it?


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


[Lazarus] DBNavigator: why is the refresh button enabled only if the dataset is modifiable?

2019-10-16 Thread Luca Olivetti via lazarus
In lcl/include/dbcustomnavigator.inc, method 
TDBCustomNavigator.EditingChanged


CanModify:=Enabled and FDataLink.Active and FDataLink.DataSet.CanModify;
...
Buttons[nbRefresh].Enabled:=CanModify;



Why?

I mean, I have a read only query (specifically a TZReadOnlyQuery) since 
I only want to show the data, but another application can change it, 
hence a refresh could be needed.


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Juha Manninen via lazarus
On Wed, Oct 16, 2019 at 4:41 PM Werner Pamler via lazarus
 wrote:
> I don't know what you are referring to, here. In r61814 I had added the
> "System" namespace here in VTV because fpc 3.2+ has a Move method in
> TCollection which conflicts with the old code.

r61814 in fixes branch seems to a merge from Michael's r60784 in trunk.
Your big rename commit r60132 in trunk would be useful, too, but I
guess difficult to merge.

Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Werner Pamler via lazarus

Am 16.10.2019 um 12:31 schrieb Juha Manninen via lazarus:


Your diff for VirtualTreeView replaces Move with System.Move. Why? Is
there another Move in FPC 3.2 sources that would be called otherwise?
Is your diff already applied somewhere or is it a patch uploaded into
some bug report?


I don't know what you are referring to, here. In r61814 I had added the 
"System" namespace here in VTV because fpc 3.2+ has a Move method in 
TCollection which conflicts with the old code.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Luca Olivetti via lazarus

El 16/10/19 a les 12:31, Juha Manninen via lazarus ha escrit:

On Sun, Oct 13, 2019 at 4:10 PM Luca Olivetti via lazarus
 wrote:

In my copy of lazarus 2.0.4 I have the fix for bug
https://bugs.freepascal.org/view.php?id=35716


I added it to the list to be merged for 2.0.6.


and the patch for the still opened
https://bugs.freepascal.org/view.php?id=35715


Unfortunately Jesus has not applied the patch or otherwise solved the
issue. You write "I'm not sure it's the best solution", I guess it is
a difficult case.


"I'm not sure it's the best solution" because the grid is a complex 
beast and maybe Jesus has a better one.






Also, I don't know if this will be in 2.0.6 (I need it since the bugs in
fpc 3.0.4 affect my projects, so I have to use fixes_3_2):


Your diff for VirtualTreeView replaces Move with System.Move. Why? Is
there another Move in FPC 3.2 sources that would be called otherwise?


3.2 added a new method Move to TCollection, hence the need to qualify 
the call



Is your diff already applied somewhere or is it a patch uploaded into
some bug report?


In lazarus trunk it's already changed

https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/virtualtreeview/laz.virtualtrees.pas?root=lazarus&r1=60642&r2=60784

however lazarus trunk also changed the name of the component and the 
corresponding units


https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/components/virtualtreeview/laz.virtualtrees.pas?root=lazarus&r1=60024&r2=60132

Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus


Re: [Lazarus] [Lazarusdev] RFC --- We are planning the next release: Lazarus 2.0.6

2019-10-16 Thread Juha Manninen via lazarus
On Sun, Oct 13, 2019 at 4:10 PM Luca Olivetti via lazarus
 wrote:
> In my copy of lazarus 2.0.4 I have the fix for bug
> https://bugs.freepascal.org/view.php?id=35716

I added it to the list to be merged for 2.0.6.

> and the patch for the still opened
> https://bugs.freepascal.org/view.php?id=35715

Unfortunately Jesus has not applied the patch or otherwise solved the
issue. You write "I'm not sure it's the best solution", I guess it is
a difficult case.

> Also, I don't know if this will be in 2.0.6 (I need it since the bugs in
> fpc 3.0.4 affect my projects, so I have to use fixes_3_2):

Your diff for VirtualTreeView replaces Move with System.Move. Why? Is
there another Move in FPC 3.2 sources that would be called otherwise?
Is your diff already applied somewhere or is it a patch uploaded into
some bug report?

Regards,
Juha
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus