Re: [Lazarus] Assign not working on text files (fwd)

[Michael Van Canneyt]

Hello,

Sent to me, but I am forwarding it to the list because it contains a question 
for everyone.

There is no global class chart, to my knowledge. 
The FPC docs have a chart, but it only covers non-visual components (essentially, the FCL classes).

With fpdoc there is a tool that creates a class chart in postscript 
(fpclasschart).

Michael.

-- Forwarded message --
Date: Sun, 9 Nov 2014 19:45:46 + (UTC)
From: Stefanos Beligiannis 
To: Michael Van Canneyt 
Subject: Re: [Lazarus] Assign not working on text files

Thank you Michael,
Thank you Bart,

The problem solved with your advice.
Another problem issued below, (I didn't mention it) with a close(f) solved also 
by changing it to closefile(f)

Michael thank you because you explanation made me understand better what's in 
it.

I have to study the classes carefully to develop in Lazarus and it would be 
very helpful that diagram of the classes which I can't find it to download.

Any way does anybody has tried to program platforms like AutoCAD and ArcGIS 
through Lazarus? As new in Lazarus I would appreciated any opinion on using dll 
libraries.

Brgds
Stefanos
 

___
From: Michael Van Canneyt 
To: Lazarus mailing list 
Cc: Stefanos Beligiannis 
Sent: Sunday, November 9, 2014 5:50 PM
Subject: Re: [Lazarus] Assign not working on text files





On Sun, 9 Nov 2014, Bart wrote:


On 11/9/14, Stefanos Beligiannis  wrote:


If somebody has met this problem please advise.
code var    f : text;
    fn,nam : string;

begin
      fn:=Edit2.Caption;
      {$I-}
      assign(f,fn);
      if (not FileExists(fn)) then Rewrite(f) else Append(f);
      {$I+}- end codecompiler error
report-  startk2u.pas(92,18) Error: Wrong number of
parameters specified for call to "Assign"k2u.pas(93,44) Hint: Local variable
"f" does not seem to be initialized- end
use Lazarus # 1.2.6





Use TextFile instead of Text, use AssignFile instead of Assign.
Alternatively prepend both Text and Assign with system. (note the dot!).



Explanation:

The code most likely is inside a TForm. TForm descends from TPersistent.
TPersistent has a .Assign() method, which is totally unrelated to the Assign() 
of the system unit.

When compiling your code, the compiler needs to know which Assign() to use.
It finds first the TPersistent.Assign, stops searching and gives an error
because it has different arguments from the system version.

By prepending your "text" and "assign" with system: system.text, system.assign,
the compiler does not search in TPersistent and finds the correct routines.

Michael.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Giuliano Colla]

Il 09/11/2014 19:01, Vojtěch Čihák ha scritto:


Hi,

CalcPreferredSize is called only when Autosize is True, it's not this 
case.




No, it's called always, also when Autosize is false. It gets called 
starting from TToolButton.GetPreferredSize. In a minimal test program 
with a toolbar and Autosize false, setting a breakpoint on it, that's 
the resulting call stack:


#0 TTOOLBUTTON__CALCULATEPREFERREDSIZE(0, 0, true, ) at 
./include/toolbutton.inc:963
#1 TCONTROL__GETPREFERREDSIZE(0, 0, false, true, ) at 
./include/control.inc:5220
#2 TTOOLBUTTON__GETPREFERREDSIZE(0, 0, false, true, ) 
at ./include/toolbutton.inc:738
#3 CALCULATEPOSITION(0xb150) at ./include/toolbar.inc:566
#4 TTOOLBAR__WRAPBUTTONS(531, 0, 0, false, ) at 
./include/toolbar.inc:818
#5 TTOOLBAR__CONTROLSALIGNED() at 
./include/toolbar.inc:160
#6 TWINCONTROL__ALIGNCONTROLS(0x0, {LEFT = 1, TOP = 2, RIGHT = 531, BOTTOM = 23, 
TOPLEFT = {X = 1, Y = 2}, BOTTOMRIGHT = {X = 531, Y = 23}}, ) at ./include/wincontrol.inc:3212
#7 TWINCONTROL__ALIGNCONTROL(0x0, ) at 
./include/wincontrol.inc:6289
#8 AUTOSIZECONTROL(0xb7fcce60, 0xb3f4) at ./include/control.inc:2846
#9 AUTOSIZECONTROL(0xb7fcafa0, 0xb3f4) at ./include/control.inc:2848
#10 TCONTROL__DOALLAUTOSIZE() at 
./include/control.inc:2896
#11 TWINCONTROL__DOALLAUTOSIZE() at 
./include/wincontrol.inc:3504
#12 TCONTROL__ENABLEAUTOSIZING() at 
./include/control.inc:5450
#13 TCONTROL__SETVISIBLE(true, ) at 
./include/control.inc:4290
#14 TCUSTOMFORM__SETVISIBLE(true, ) at 
./include/customform.inc:486
#15 TCUSTOMFORM__SHOW() at ./include/customform.inc:2196
#16 TAPPLICATION__RUN() at 
./include/application.inc:1387
#17 main at toolbutton.lpr:19



Furthermore, I found this code in Componenteditors.pas in

procedure TToolBarComponentEditor.ExecuteVerb(Index: Integer);

around line 1255:

if NewStyle = tbsDivider then
  NewToolButton.Width := 3;

IMO if default with of divider was 5 before that patch then there is 
something wrong elsewhere.




No need to search elsewhere. This just explains why after the patch the 
Divider width has become 3 pixels. Before the patch, the line you 
mention had no effect, because it was overridden by the PreferredSize 
settings of the component. But the side effect is that now also an 
horizontal divider in a vertical toolbar has become 3 pixels wide, which 
is not what was intended.
And it also explains why a Separator which was 10 pixels wide now has 
the same size of a button, because the style tbsSeparator is not 
considered in this portion of code.




About changing orientation from horizontal to vertical:

I will look at it, frankly, I never used vert. toolbars so I didn't 
test it.




Never did I in the past, but it's been requested for the editortoolbar, 
so I've been forced to look into it.


Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Done in the bug report.

Thanks.
Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Dmitry Boyarintsev]

On Sun, Nov 9, 2014 at 4:42 PM, Antônio  wrote:

> Should I post the files here:?
>
> You could post the diff file here or you could attach it to the bug report
you've already created.

thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Should I post the files here:?
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Dmitry Boyarintsev]

On Sun, Nov 9, 2014 at 4:37 PM, Antônio  wrote:

> In fact the method name is GetSelectionColor, which is not coincident with
> any other method you could have written before.
>
So let's trade.
You share your code, I share the knowledge of what is wrong with it.

thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

In fact the method name is GetSelectionColor, which is not coincident with
any other method you could have written before.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Before this I have added an empty clone method in WSRichMemo.

Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Forget what I wrote on that bugreport. Now I have added to
TWin32WSCustomRichMemo.

class function TWin32WSCustomRichMemo.GetColor(const AWinControl:
TWinControl) :TColor;
begin
  SayHello;   // this fails
end;
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Dmitry Boyarintsev]

Antônio

I can only guess that the changes you're talking about were reported here:
http://bugs.freepascal.org/view.php?id=27009

>From the changes I can see noted there, they're done not quite accurate
manner.
For example, Windows specific code is moved to TWSCustomRichMemo class
(WSRichMemo.pas).

However, for the Win-widgetset the code should be added to
TWin32WSCustomRichMemo (win32richmemo.pas)
Since TWin32WSCustomRichMemo drives RichMemo for Windows .
TWSCustomRichMemo is only used for "unsupported" widgetset (such as Qt) or
projected widgetsets (such as Cocoa)

thanks,
Dmitry

On Sun, Nov 9, 2014 at 3:48 PM, Antônio  wrote:

> Dear Dimitry,
>
> I have the RichMemo Revision 3703 version and I am trying to implement
> some extra features. I have made this for 2 ou 3 methods, but now I have a
> method which does not respond. I don't know why this occurs and if you
> could clarify this I would appreciate.
>
> Antônio
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Dmitry Boyarintsev]

On Sun, Nov 9, 2014 at 3:26 PM, Antônio  wrote:

> So what the hell do class procedure TCustomRichMemo.WSRegisterClass?
>
> It associates the LCL TCustomRichMemo with a certain WS-handler class.

That's necessary at the time TRichMemo is allocated by LCL it would receive
a proper WS-level handler associated.
If there's no WS-specific handler registered/implemented, then TRichMemo
would still be allocated by won't do have any RichMemo specific
functionality.
As an example Qt widgetset doesn't have any implementation of RichMemo
handles. However, an application using RichMemp could still be allocated.

Please note that WSRegisterClass is necessary for controls that heavily
depend on the underlying widgetset. Pure cross-platform controls don't need
this kind of bindings.

thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Dear Dimitry,

I have the RichMemo Revision 3703 version and I am trying to implement some
extra features. I have made this for 2 ou 3 methods, but now I have a
method which does not respond. I don't know why this occurs and if you
could clarify this I would appreciate.

Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

I know it is called.

Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Hi, Dimitry

So what the hell do class procedure TCustomRichMemo.WSRegisterClass?

Thanks,
Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Dmitry Boyarintsev]

On Sun, Nov 9, 2014 at 6:27 AM, Antônio  wrote:

> The control is TRichMemo.
>
> Hello Antônio

Need to be noted that RichMemo is not part of standard LCL but a separate
package.
Thus it has its own set of "register" process.

See richmemofactory.pas. This is the place where the Widgetset-specific
RichMemo implementation is registered with LCL-RichMemo class.

thanks,
Dmitry
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

I have already said, I think:

function WSRegisterCustomX: Boolean; external name 'WSRegisterCustomX';

{...}

class procedure TCustomX.WSRegisterClass;
begin
  inherited;
  WSRegisterCustomX;
end;

Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Vojtěch Čihák]

Hi,
 
CalcPreferredSize is called only when Autosize is True, it's not this case.
 
Furthermore, I found this code in Componenteditors.pas in
procedure TToolBarComponentEditor.ExecuteVerb(Index: Integer);
around line 1255:
 
if NewStyle = tbsDivider then
  NewToolButton.Width := 3; 
 
IMO if default with of divider was 5 before that patch then there is something 
wrong elsewhere.
 
About changing orientation from horizontal to vertical:
I will look at it, frankly, I never used vert. toolbars so I didn't test it.
 
Thanks for pointing it,
 
Vojtěch 
__

Od: Giuliano Colla 
Komu: Lazarus mailing list 
Datum: 09.11.2014 17:41
Předmět: Re: [Lazarus] Toolbar divider issues



Il 09/11/2014 15:04, Vojtěch Čihák ha scritto:


Hi,

with this code:

procedure TToolButton.SetStyle(Value: TToolButtonStyle);
begin
  if FStyle = Value then exit;
  FStyle := Value;
  if Value = tbsSeparator then Width := 10;
  if Value = tbsDivider then Width := 5;
  InvalidatePreferredSize;
  if IsControlVisible then
  UpdateVisibleToolbar;
end;

It now does deault 10px separators - both design-time and code

and 5px dividers from code but still 3px dividers at design-time.

EditorToolBar looks better now. I'll find solution and I'll send a 
patch to bugtracker.




If you look into the matter, please do not forget that a toolbar can be 
either horizontal or vertical.


From TToolbutton.CalculatePreferredSize:

...
    if Style = tbsDivider then
      if FToolBar.IsVertical then
        PreferredHeight := 5
      else
        PreferredWidth := 5
    else
    if Style = tbsSeparator then
      if FToolBar.IsVertical then
        PreferredHeight := 10
      else
        PreferredWidth := 10;
  end;

In an ideal world, if the user doesn't set a different width or height, 
the preferred values should go into effect, in any configuration, for 
any visual component.
But in a toolbar there's another constraint: if it's horizontal all 
buttons must share the same height, it it's vertical all buttons must 
share the same width, overriding some of the user settings.

That's what makes it a little bit tricky.

Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus 


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Mattias Gaertner]

On Sat, 8 Nov 2014 22:29:02 -0200
Antônio  wrote:

> function WSRegisterCustomX: Boolean; external name 'WSRegisterCustomX';
> 
> {...}
> 
> class procedure TCustomX.WSRegisterClass;
> begin
>   inherited;
>   WSRegisterCustomX;
> end;
>[...]
> > What does WSRegisterCustomX do?

And?

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Giuliano Colla]

Il 09/11/2014 17:39, Giuliano Colla ha scritto:


Il 09/11/2014 15:04, Vojtěch Čihák ha scritto:


[...]


If you look into the matter, please do not forget that a toolbar can 
be either horizontal or vertical.


[...]


Another issue: prior to the patch, changing orientation from horizontal 
to vertical, the previous implementation assigned the proper width and 
height to separators and dividers. After the patch, they are adjusted 
for height, but they keep the previous value for width, which is 
completely wrong.


Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Giuliano Colla]

Il 09/11/2014 15:04, Vojtěch Čihák ha scritto:


Hi,

with this code:

procedure TToolButton.SetStyle(Value: TToolButtonStyle);
begin
  if FStyle = Value then exit;
  FStyle := Value;
  if Value = tbsSeparator then Width := 10;
  if Value = tbsDivider then Width := 5;
  InvalidatePreferredSize;
  if IsControlVisible then
  UpdateVisibleToolbar;
end;

It now does deault 10px separators - both design-time and code

and 5px dividers from code but still 3px dividers at design-time.

EditorToolBar looks better now. I'll find solution and I'll send a 
patch to bugtracker.




If you look into the matter, please do not forget that a toolbar can be 
either horizontal or vertical.


From TToolbutton.CalculatePreferredSize:

...
if Style = tbsDivider then
  if FToolBar.IsVertical then
PreferredHeight := 5
  else
PreferredWidth := 5
else
if Style = tbsSeparator then
  if FToolBar.IsVertical then
PreferredHeight := 10
  else
PreferredWidth := 10;
  end;

In an ideal world, if the user doesn't set a different width or height, 
the preferred values should go into effect, in any configuration, for 
any visual component.
But in a toolbar there's another constraint: if it's horizontal all 
buttons must share the same height, it it's vertical all buttons must 
share the same width, overriding some of the user settings.

That's what makes it a little bit tricky.

Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TFMTBCDField problem

[Chris Rempas]

I am almost convinced that the problem is not what i am seeing...this code works
if VSQLVar^.sqlscale = 0 then  i := AParams[ParNr].AsIntegerelse//i := 
Round(AParams[ParNr].AsCurrency * IntPower10(-VSQLVar^.sqlscale));
  i := Round(BCDToDouble(AParams[ParNr].AsFMTBCD) * 
IntPower10(-VSQLVar^.sqlscale));

the reason i think that this is not a *real* fix, is that the TParam.asCurrency 
returns a Varriant and this raises the error, but TParam.AsFMTBCD returns a 
TFMTBCD Value converted from a variant! This *should* raise the same error, but 
it doesn't
How could i have debug info in FMTBCD unit? i would like to take a look at this 
BCDFactory

PS : I am really trying to fix the problem and not just patch around it, i have 
the highest hope in your understanding and help :)
Regards,Chris


 On Sunday, November 9, 2014 12:08 PM, Joost van der Sluis  
wrote:
   

 On 11/09/2014 03:37 AM, Chris Rempas wrote:
> I copied the binaries that were missing in my FPC 2.7.1 from FPC2.6.4
> i run make clean all and make install again and VOILA! i have debug! :)))
> (it seems all the binaries must be in the same directory for some reason)

I don't really understand which binaries you did copy. But I'm glad you 
have the debug-info.

> FILE "dsparams.inc", LINE 519
> Function TParam.GetAsCurrency: Currency;
> begin
>    If IsNull then
>      Result:=0.0
>    else
>      Result:=FValue;    < 519
> end;

For 'BCD' fields, the Currency type is used. In your case you have 5 
decimals, so you can not use .AsCurrency...

> when the parser gets the values of the params, this param is BCD and as
> you can see it tries to get it as currency
>
> In a quick check, methods [AssignToField] [AssignFromField] [GetData]
> [SetData] are not fully ready for every "FDataType"
> some are missing BCD Fields, some are missing FMTBCD Fields and
> sometimes it gets the same treatment as Currency...

Currency and BCD are the same. So apparently support for FMTBCD fields 
is missing here. As the FMTBCD support is relatively new this could just 
be missing.

> I am guessing at this point that i don't have the latest code
>
> if i could have a copy of the latest component, i would be able to test
> and maybe help debug with real testing

2.7.1 is the latest version? Yo have to find out where/why the FMTBCD 
param is accesses as AsCurrency (Assign, GetData, SetData?), and fix 
that. Then you can simply recompile fcl-db and see if your program works.

Oh, and if you have fixed the problem, send us a patch. ;)

Joost.



   --
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Assign not working on text files

[Michael Van Canneyt]

On Sun, 9 Nov 2014, Bart wrote:


On 11/9/14, Stefanos Beligiannis  wrote:


If somebody has met this problem please advise.
code varf : text;
fn,nam : string;

begin
 fn:=Edit2.Caption;
 {$I-}
 assign(f,fn);
 if (not FileExists(fn)) then Rewrite(f) else Append(f);
 {$I+}- end codecompiler error
report-  startk2u.pas(92,18) Error: Wrong number of
parameters specified for call to "Assign"k2u.pas(93,44) Hint: Local variable
"f" does not seem to be initialized- end
use Lazarus # 1.2.6





Use TextFile instead of Text, use AssignFile instead of Assign.
Alternatively prepend both Text and Assign with system. (note the dot!).


Explanation:

The code most likely is inside a TForm. TForm descends from TPersistent.
TPersistent has a .Assign() method, which is totally unrelated to the Assign() 
of the system unit.

When compiling your code, the compiler needs to know which Assign() to use.
It finds first the TPersistent.Assign, stops searching and gives an error 
because it has different arguments from the system version.


By prepending your "text" and "assign" with system: system.text, system.assign,
the compiler does not search in TPersistent and finds the correct routines.

Michael.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Assign not working on text files

[Bart]

On 11/9/14, Stefanos Beligiannis  wrote:

> If somebody has met this problem please advise.
> code varf : text;
> fn,nam : string;
>
> begin
>  fn:=Edit2.Caption;
>  {$I-}
>  assign(f,fn);
>  if (not FileExists(fn)) then Rewrite(f) else Append(f);
>  {$I+}- end codecompiler error
> report-  startk2u.pas(92,18) Error: Wrong number of
> parameters specified for call to "Assign"k2u.pas(93,44) Hint: Local variable
> "f" does not seem to be initialized- end
> use Lazarus # 1.2.6
>
>
>

Use TextFile instead of Text, use AssignFile instead of Assign.
Alternatively prepend both Text and Assign with system. (note the dot!).

Bart

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Assign not working on text files

[Stefanos Beligiannis]

If somebody has met this problem please advise.
code var    f : text;
    fn,nam : string;
  
begin
 fn:=Edit2.Caption;
 {$I-}
 assign(f,fn);
 if (not FileExists(fn)) then Rewrite(f) else Append(f);
 {$I+}- end codecompiler error report-  
startk2u.pas(92,18) Error: Wrong number of parameters specified for call to 
"Assign"k2u.pas(93,44) Hint: Local variable "f" does not seem to be 
initialized- end
use Lazarus # 1.2.6


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Vojtěch Čihák]

Hi,
 
with this code: 
 
procedure TToolButton.SetStyle(Value: TToolButtonStyle);
begin
  if FStyle = Value then exit;
  FStyle := Value;
  if Value = tbsSeparator then Width := 10;
  if Value = tbsDivider then Width := 5;
  InvalidatePreferredSize;
  if IsControlVisible then
  UpdateVisibleToolbar;
end;
 
It now does deault 10px separators - both design-time and code
and 5px dividers from code but still 3px dividers at design-time.
 
EditorToolBar looks better now. I'll find solution and I'll send a patch to 
bugtracker. 
 
Vojtěch 

___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus 


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Toolbar divider issues

[Vojtěch Čihák]

Hi,
 
@Is that expected, or it must be considered a bug?
 
That depends. Bugreport title is "ToolBar separator can't change width."
Now all dividers and separators on TToolBar can have different width.
 
Therefore, saying "when created in code both Separator and 
divider are 23 pixels,..." is meaningless, because now, what you set is what you get:

 
procedure TForm1.Button2Click(Sender: TObject);
var aTBtn: TToolButton;
begin
aTBtn:=TToolButton.Create(self);
aTBtn.Style:=tbsSeparator;
aTBtn.Width:=10;
aTBtn.Parent:=ToolBar1;
end;

procedure TForm1.Button3Click(Sender: TObject);
var aTBtn: TToolButton;
begin
aTBtn:=TToolButton.Create(self);
aTBtn.Style:=tbsDivider;
aTBtn.Width:=5;
aTBtn.Parent:=ToolBar1;
end;
 
Currently, there's probably nothing like default width of separator or divider.
 
I can look on it, maybe adding code to Style setter would solve it:
 
procedure TToolButton.SetStyle(Value: TToolButtonStyle);
begin
  if FStyle = Value then exit;
  FStyle := Value;
  if Value = tbsSeparator then Width := 10;
  if Value = tbsDivider then Width := 5;
  InvalidatePreferredSize;
  if IsControlVisible then
  UpdateVisibleToolbar;
end;  
 
I'll test it. 
 
Vojtěch 
__


Od: Giuliano Colla 
Komu: Lazarus mailing list 
Datum: 09.11.2014 11:57
Předmět: [Lazarus] Toolbar divider issues

With rev 46741 (patch from bug 25291) the default width of Toolbar 
Divider and Separator has become inconsistent.


Before the patch, both from IDE designer and from component created in 
code, Separator width was 10 pixels, and Divider width 5 pixels.


After the patch, from IDE designer Separator width has become 23 pixels, 
and Divider width 3 pixels; when created in code both Separator and 
divider are 23 pixels, as it can be seen in Editortoolbar.


Giuliano
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus 


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TWin32WSCustomX class

[Antônio]

Sorry for the big message, Gnail hides me the rest of the message.

The control is TRichMemo.

Antônio
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Toolbar divider issues

[Giuliano Colla]

With rev 46741 (patch from bug 25291) the default width of Toolbar 
Divider and Separator has become inconsistent.


Before the patch, both from IDE designer and from component created in 
code, Separator width was 10 pixels, and Divider width 5 pixels.


After the patch, from IDE designer Separator width has become 23 pixels, 
and Divider width 3 pixels; when created in code both Separator and 
divider are 23 pixels, as it can be seen in Editortoolbar.


Is that expected, or it must be considered a bug?

Giuliano

--
Giuliano Colla

Project planning question: when it's 90% done, are we halfway or not yet?


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus