Re: [fpc-pascal] Anchors on a child form

[Giuliano Colla]

Il 04/06/2018 14:06, Martin Wynne ha scritto:

uses Unit1;

procedure TForm2.FormCreate(Sender: TObject);
begin
  Parent:=Form1;
  Anchors:=[];
  Visible:=True;
end;

4. run it, and the debugger will show the error message. 


Just remove the two lines

Parent:= Form1; (which is wrong, because it makes Form2 a widget inside 
Form1)


and

Anchors:=[]; (which is useless)

And it will work.

Giuliano

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

> On Jun 4, 2018, at 9:12 PM, Michael Van Canneyt  
> wrote:
> 
> All the rest of what you do remains exactly the same. Dynamic arrays do far 
> less than what you seem to assume.

As noted the inclocked()/declocked() calls destroyed some performance sensitive 
parts of my code while testing and I had a choice to try to figure out the FPC 
or sources or just replace the dynamic arrays with my own memory management 
(totally trivial anyways). The dynamic arrays where inside of a class which I 
had to make anyways so I could extend the dynamic arrays to have append 
operations and optionally not resize memory when removing elements (I don’t 
know if dynamic arrays do that or not, who knows). I wish I kept the old 
performance profiles so we could look at them again.

It’s so trivial to make a class wrapper around simple memory management like 
arrays I felt like it was strange to use a hidden implementation that I 
couldn’t control 100%. It feels like RTL kind of stuff.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

> On Jun 4, 2018, at 9:21 PM, Martin Schreiber  wrote:
> 
> It seems that the inclocked()/declocked() operations completely destroy the 
> performance of the OP's application (which I find strange) so he never want 
> to touch dynamic arrays anymore as he wrote.

It was one hyper sensitive part of a sorting algorithm and it may have been a 
bug for all I know but it was less work to replace dynamic arrays with 
GetMem/FreeMem and get on with the day.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Martin Schreiber]

On Monday 04 June 2018 16:12:27 Michael Van Canneyt wrote:
>
> They make life easier by reducing the need for manual memory
> management. No more, no less. Other than that they behave like normal
> arrays on the heap.
>
It seems that the inclocked()/declocked() operations completely destroy the 
performance of the OP's application (which I find strange) so he never want 
to touch dynamic arrays anymore as he wrote.

Martin
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Michael Van Canneyt]

On Mon, 4 Jun 2018, Ryan Joseph wrote:





On Jun 4, 2018, at 5:46 PM, Michael Van Canneyt  wrote:

Well, as far as I can see, you are repeating what the compiler already does for 
you out of the box.


But it’s customizable, that’s the point. What happens when you remove an 
element from a dynamic array? I don’t even know where to look in the source 
code to find out and if I want to change something I can’t. Do dynamic arrays 
resize memory when you remove elements? Maybe I don’t want that. Maybe I want 
to grow the array at different intervals, can’t do that either.

I know this is very fringe but I personally needed to customize dynamic arrays 
to escape that thread safety thing and when I couldn’t I had to make my own 
array wrapper class which I would have preferred to be a record in many 
instances, which I can do now. If nothing else it saves me lots of Create/Free 
calls in countless functions. Pretty good news.

If I actually made a competent implementation (which I’ll do later) dynamic 
arrays are possibly made redundant even, or close to it (providing the FPC RTL 
had something like them included).


I do not advocate that you drop your custom record.

I'm just saying that *the management operators* are not needed for your
use-case, based on what I see, if you would use dynamic arrays instead of
manually managing the memory. It will simplify your code.

All the rest of what you do remains exactly the same. 
Dynamic arrays do far less than what you seem to assume.


All in all, it seems to me that you do not actually know what dynamic
arrays are really about, so instead of spending a lot of time
re-implementing what is there, maybe better learn what they do 
(and don't do).


They make life easier by reducing the need for manual memory
management. No more, no less. Other than that they behave like normal
arrays on the heap.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

> On Jun 4, 2018, at 5:46 PM, Michael Van Canneyt  
> wrote:
> 
> Well, as far as I can see, you are repeating what the compiler already does 
> for you out of the box.

But it’s customizable, that’s the point. What happens when you remove an 
element from a dynamic array? I don’t even know where to look in the source 
code to find out and if I want to change something I can’t. Do dynamic arrays 
resize memory when you remove elements? Maybe I don’t want that. Maybe I want 
to grow the array at different intervals, can’t do that either.

I know this is very fringe but I personally needed to customize dynamic arrays 
to escape that thread safety thing and when I couldn’t I had to make my own 
array wrapper class which I would have preferred to be a record in many 
instances, which I can do now. If nothing else it saves me lots of Create/Free 
calls in countless functions. Pretty good news.

If I actually made a competent implementation (which I’ll do later) dynamic 
arrays are possibly made redundant even, or close to it (providing the FPC RTL 
had something like them included).

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Anchors on a child form

[Martin Wynne]

Hi Mattias,

Thanks for your reply.


'TWinControl.WMSize loop detected, the widgetset does not like the LCL
bounds or sends unneeded wmsize messages'.


Can you create a bug report with an example to reproduce the loop?


Sorry, I don't know how to do that. However, it is very easy to replicate:

1. start a new project application.
2. add an additional new form.
3. in Form2 add:

uses Unit1;

procedure TForm2.FormCreate(Sender: TObject);
begin
  Parent:=Form1;
  Anchors:=[];
  Visible:=True;
end;

4. run it, and the debugger will show the error message.


Can you give more details, what the Delphi program does?


In Delphi5 setting Parent:=Form1 causes Form2 to behave very similarly 
to a TPanel with the addition of some form properties. It has a top 
caption bar by means of which it can be dragged around on Form1, a red X 
to dismiss it, and it can be resized by dragging the edges/corners.


But it never gains focus or an "Active" border. Focus remains with Form1 
at all times. If there are underlined keyboard accelerator keys on its 
controls, they are merged with any on Form1 and on any other child forms.


For a graphical drawing program it makes a very useful floating toolbox 
which the user can drag around and/or resize to avoid obscuring the 
drawing. My application uses several of them, some quite large which 
wouldn't fit into a top toolbar.


In Lazarus it initially looks similar, but can't be dragged around and 
behaves strangely if resized. I hoped to cure that by removing the 
anchors, but then got the error message above.


It can be cured by using Windows.SetParent instead of Parent:=, but now 
the child form gains focus and an Active border whenever it is dragged 
or its controls are clicked. Which is a nuisance for the user because 
the parent form loses focus and the expected keyboard shortcuts no 
longer work until the parent form is clicked.


Thanks for any help.

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Nitorami]

>> It would be reasonable to assume that the predefined + might be
>> substantially more efficient than a programmer-defined one could be.

>Yes, that's one of the reasons I vote for keeping the new feature
>and allow to overload the operator. 

I don't think that argument holds water. Concatenation of dynamic structures
is a slow function in the first place. I am not a core developer, but I
consider that regardless how you do it, it will require a call to setlength,
which in turn will call the operating system to allocate memory for the now
larger structure. That takes much more time than a few assembly instructions
for a normal pascal procedure call. 



--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

> On Jun 4, 2018, at 4:39 PM, Michael Van Canneyt  
> wrote:
> 
> The array is private. This means that the reference count will be 0 or 1.

I looked at the examples on the wiki and think by private you mean that the ref 
count does indeed need to be a pointer so it gets updated for all references. I 
didn’t get that until just now. Since there’s already an array for the elements 
I guess just allocate all members of the record into a single block of the 
memory with the elements on the end. Thanks for pointing that out, I’ll fix it 
later.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Anchors on a child form

[Mattias Gaertner]

On Sun, 3 Jun 2018 13:06:59 +0100
Martin Wynne  wrote:

> If I create a child form by setting Parent:=other_form; in FormCreate, 
> it cannot be dragged to a new position by the user.

Correct. Setting aForm.Parent makes the form a "normal" control like a
frame or panel. If you want dragging, you need to do the same as for
any other LCL control: 
http://wiki.freepascal.org/LCL_Drag_Drop

 
> If I then remove the top and left anchors by setting Anchors:=[]; in 
> FormCreate (or in the Object Inspector) so that it can be dragged, I get 
> this exception:

Removing anchors won't give you dragging. It centers a control on its
parent client area.

 
> 'TWinControl.WMSize loop detected, the widgetset does not like the LCL 
> bounds or sends unneeded wmsize messages'.

Can you create a bug report with an example to reproduce the loop?

 
> I have tried setting
> 
> Windows.SetParent(Handle,other_form.Handle); (instead of 
> Parent:=other_form;)
> 
> which removes the exception, but the child form then retains focus after 
> use, preventing the parent form from responding to the keyboard (which 
> defeats the object of using a child form in the first place).
> 
> I'm porting a project to Lazarus from Delphi5, where it works fine. 
> Child forms can be dragged around even with the top and left anchors set.

Can you give more details, what the Delphi program does?

Mattias
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Anchors on a child form

[Martin Wynne]

This appears to be a topic for the Lazarus list, as it appears that 
you're using the Lazarus LCL: laza...@lists.lazarus-ide.org


There you may obtain adequate assistance.

Giuliano


Thanks. Sorry for posting to the wrong list.

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Michael Van Canneyt]

On Mon, 4 Jun 2018, Ryan Joseph wrote:





On Jun 4, 2018, at 4:39 PM, Michael Van Canneyt  wrote:

I fail to see why you need management operators for this.


just because I wanted the array implementation available and to get automatic 
cleanup. I don’t know all the stuff dynamic arrays do behind the scenes and 
that worries me (see below).


Well, as far as I can see, you are repeating what the compiler already does for 
you out of the box.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

> On Jun 4, 2018, at 4:39 PM, Michael Van Canneyt  
> wrote:
> 
> I fail to see why you need management operators for this.

just because I wanted the array implementation available and to get automatic 
cleanup. I don’t know all the stuff dynamic arrays do behind the scenes and 
that worries me (see below).

> 
> If you declare your array in the record as a dynamic array, everything
> will be done for you.
> 
> The array is private. This means that the reference count will be 0 or 1.
> When the record goes out of scope, the compiler code will free it.
> 
> Unless I missed something which is always a possibility.

The ref counting is basically useless right now because the record needs to be 
passed by reference. All the internals like the ref count need to be stored as 
a pointer I think but I wanted this to be bare-bones and fast. Anyways it’s 
really just for single functions or globals, otherwise I’d use a class.

Mainly I just thought it was cool FPC can finally do this and if you wanted to 
you could make a robust implementation that did real ref counting. I had the 
problem with thread locking code getting called and killing performance so I 
won’t use dynamic arrays anymore because I don’t trust them. Using management 
operators with manual memory allocation gives you access to the implementation 
also in case you need to change something or need performance tuning (distrust 
of dynamic arrays really drives this idea for me). If I want to change 
something about dynamic arrays implementation it’s probably impossible for me 
personally to figure it out.

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Anchors on a child form

[Giuliano Colla]

Il 03/06/2018 14:06, Martin Wynne ha scritto:
I'm porting a project to Lazarus from Delphi5, where it works fine. 
Child forms can be dragged around even with the top and left anchors set.


Thanks for any help in fixing this


This appears to be a topic for the Lazarus list, as it appears that 
you're using the Lazarus LCL: laza...@lists.lazarus-ide.org


There you may obtain adequate assistance.

Giuliano


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Dynamic arrays using management operators

[Michael Van Canneyt]

On Mon, 4 Jun 2018, Ryan Joseph wrote:


Since we were talking about dynamic arrays I was curious to see if they could 
be implemented using the new management operators so I made a little proof of 
concept by cobbling together old code. It’s not complete or very good by any 
means but I think it’s a pretty interesting alternative to using dynamic 
arrays. Being able to add operators and methods is nice, especially since type 
helpers (that we could use on dynamic arrays) are so limited by single scopes 
currently. Specifically it’s nice to just declare an array and say “a += 1” 
without anything else. Having the implementation in a unit is good also in case 
you need to mess with something for specific performant reasons.

Not sure if this is useful or not but it’s certainly a milestone for Pascal to 
be able to make complex data types that integrate so well into the language and 
are so easy to use and manage.

https://github.com/genericptr/Managed-Arrays-Dictionaries


I fail to see why you need management operators for this.

If you declare your array in the record as a dynamic array, everything
will be done for you.

The array is private. This means that the reference count will be 0 or 1.
When the record goes out of scope, the compiler code will free it.

Unless I missed something which is always a possibility.

Michael.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Dynamic arrays using management operators

[Ryan Joseph]

Since we were talking about dynamic arrays I was curious to see if they could 
be implemented using the new management operators so I made a little proof of 
concept by cobbling together old code. It’s not complete or very good by any 
means but I think it’s a pretty interesting alternative to using dynamic 
arrays. Being able to add operators and methods is nice, especially since type 
helpers (that we could use on dynamic arrays) are so limited by single scopes 
currently. Specifically it’s nice to just declare an array and say “a += 1” 
without anything else. Having the implementation in a unit is good also in case 
you need to mess with something for specific performant reasons.

Not sure if this is useful or not but it’s certainly a milestone for Pascal to 
be able to make complex data types that integrate so well into the language and 
are so easy to use and manage.

https://github.com/genericptr/Managed-Arrays-Dictionaries

TIntArray = specialize TDynArray;

var
  a: TIntArray;
begin
  d.AddValues([1, 2, 3]); // := assignment operator for implicit arrays [] are 
broken currently
  a += 4;
  for i in a do
writeln(i);
end;

TIntDict = specialize TDynDictionary;

var
  dict: TIntDict;
  entry: TIntDict.TEntryPtr;
begin
  dict.SetValues([
'a', 1,
'b', 2
   ]);
  dict.SetValue('c', 3);

  if dict['a'] = 1 then
writeln('a = 1');

  for entry in dict do
  if entry^.IsValid then
writeln(entry^.key, ' => ', entry^.value);
end;


Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: Dynamic array extensions

[Bernd Oppolzer]

Am 03.06.2018 um 18:12 schrieb Sven Barth via fpc-pascal:
Bernd Oppolzer > schrieb am So., 3. Juni 2018, 11:56:




Am 02.06.2018 um 15:14 schrieb Sven Barth via fpc-pascal:

Mark Morgan Lloyd mailto:markmll.fpc-pas...@telemetry.co.uk>> schrieb am Sa., 2.
Juni 2018, 10:53:

However as Dennis points out + is also essential for vector
operations.
Perhaps either leaving it to the programmer to define what's
needed
would be the best approach, or alternatively splitting
dynamic arrays
into mathematical vectors and non-mathematical collections.
Or relaxing
the requirement that only predefined operators can be
redefined, so that
something like _ could be used for concatenation.


That needlessly complicates the parser as the compiler still
needs to know them and they also need to be part of its operator
precedence rules. Don't complicate the language for nothing! And
in the end operator overloads are one of the best examples for
syntactic sugar as you can easily achieve the same result with
functions and methods.

Regards,
Sven



This is somehow off topic of course,
but IMO it is strange to use + for string concatenation;
I always have bad feelings about this. This whole thread would
not exist, if FreePascal had gone another direction like PL/1, for
example,
where the string concatenation operator is ||
(and DB2, and - probably - other SQL dialects).


FPC inherited the +-operator for concatenation from the base language: 
Pascal. So there simply was no other route to take (not that anyone 
would have thought to take a different route).



Where does this + for string concat come from?


Ask Wirth, he is the one who invented Pascal...



AFAIK, the Pascal Standard (ISO) does not tell anything about strings
and concatenation. Wirth did not include varying length strings into
the language in the 197x years. Every Pascal compiler which contains
strings and concatenation does this by extending the Pascal Standard
and can choose its own way to do it.

IBMs Pascal/VS uses || for string concatenation (inspired by PL/1, 
probably),

and that's what I implemented in the New Stanford Pascal compiler, too.

The + for concatenation must be an invention of Turbo Pascal or UCSD Pascal
or something like that.


Regards,
Sven



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Anchors on a child form

[Martin Wynne]

If I create a child form by setting Parent:=other_form; in FormCreate, 
it cannot be dragged to a new position by the user.


If I then remove the top and left anchors by setting Anchors:=[]; in 
FormCreate (or in the Object Inspector) so that it can be dragged, I get 
this exception:


'TWinControl.WMSize loop detected, the widgetset does not like the LCL 
bounds or sends unneeded wmsize messages'.


I have tried setting

Windows.SetParent(Handle,other_form.Handle); (instead of 
Parent:=other_form;)


which removes the exception, but the child form then retains focus after 
use, preventing the parent form from responding to the keyboard (which 
defeats the object of using a child form in the first place).


I'm porting a project to Lazarus from Delphi5, where it works fine. 
Child forms can be dragged around even with the top and left anchors set.


Thanks for any help in fixing this.

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal