procedure foo;
  var a : longint;
  procedure bar;
    var b : longint;
    begin
      writeln (a);
    end;

Given the above, is there a way to make the "Locals" window display the value of "a" while stepping through the code in proc "bar"?

Thanks,
David

I believe the latest 0.9.29 snapshots can do that.

But all versions of lazarus can do it, using the stack window. In the stack window you can set the current frame to any stack-frame you want.
The local-var window, the hint, and the watches window, will all follow this

Martin

Hi,

I have learned more about Lazarus / FPC by porting some Delphi code. It seems to be very usable now, I am impressed. I must admit I considered it as a hopeless project some years ago when I first noticed it. Not any more...

But first a minor complaint. I often get errors like: Error: Illegal type conversion: "ShortString" to "^Char" or
Error: Call by var for arg no. 2 has to match exactly: Got "AnsiString" expected "ShortString"

if I don't add

  {$MODE DELPHI}

into a source file. However, I don't explicitly define any short strings. The default objfpc mode illogically thinks a "string" as function parameter is short string but other "string"s are dynamic ansistrings (or something like that).
The language has evolved and short string is mostly a historical remain. I would suggest that MODE DELPHI is made default in Lazarus or then FPC's MODE OBJFPC is fixed.

---

Then some thoughts about library internals:

It seems that LCL is designed internally better than Delphi's VCL even though they have similar components.
For example in Delphi I had a small helper function:

  procedure EnableAndBold(aButton: TButton; aEnabled: Boolean);

which enables/disables a button and sets its Font.Style accordingly. I tried to use the same func for BitBtn but no, their properties are not inherited from the same ancestor and I had to make another almost identical function:

  procedure EnableAndBold(aButton: TBitBtn; aEnabled: Boolean);

However in LCL the properties are coming from the same ancestor so I could use a single function:

  procedure EnableAndBold(aButton: TCustomButton; aEnabled: Boolean);

The same thing seems to be true for some edit controls' properties.

Good!

---

Now a question about data aware controls:
Has there ever been an idea of making dataset components and data aware controls based on interface?

The program code for data aware controls in Delphi is quite ugly. Lots of copy-pasted code and ugly hacks. DataSource maybe tries to be kind of abstraction layer there but it doesn't help much.

I think Borland (or what is it nowadays?) would use interfaces for the task now. When they first implemented it there was no interface feature available. Database connectivity was revolutionary then but now it would need an update.

The current DB components (Dataset, DataSource and edit controls) are needed to support existing code base but there should be another well designed interface based component set.
What you say?

Regards,
Juha Manninen

nope. The latest snapshots can evaluate "a", but have no knowledge if "a" is visible inside bar. And imo, "a" is not a local to bar.

And you can add "a" to your watches window.

Marc

Mode fpc is default for the compiler. If a unit is added by Lazarus it always contains {$mode objfpc}{$h+}

Marc

:-)

It is unlikely that mode objfpc will be 'fixed', it will break a lot of existing code. Therefore the default Lazarus settings are to add {$mode objfpc}{$H+} to all new files to turn on string=ansistring.

Vincent

Oh, yes. I was imprecis. I did mean hint/watches. The local doe snot do that => true.

Hi.

It is unlikely that mode objfpc will be 'fixed', it will break a lot of existing code. Therefore the default Lazarus settings are to add {$mode objfpc}{$H+} to all new files to turn on string=ansistring.

I understand the point but I don't fully agree with it.

Sometimes old code must be broken. In this case it would be enough to support old Pascal code with some mode switch. New code should be encouraged to use new language features. So, the default mode should happily swallow all new advanced language features and then maybe complain about old syntax if needed.

Pascal is an old language and its original form is quite useless in today's standards. It is alive only because extensions made by Borland and such. Other languages are evolving. To be alive after 10 years Lazarus /FPC will need some brave moves. ... but yeah, you know it already...

Back to coding. Less talk, more action.

Juha Manninen

+1

It should be possible to patch FPC for use in Lazarus.

We may have to face 3 default string types in the future:
- ShortString
- AnsiString
- UnicodeString

DoDi

The language has evolved and short string is mostly a historical remain.

Definitely not! ShortString and AnsiStrings (and all other variants of string types) are just different ways to work with strings. Using ShortStrings you can avoid a lot of problems which you can have with AnsiStrings if you don't have the need for strings longer than 255 characters.

What I would critisize is the use of the generic type "string" at all. Mapping this to different types dependend on compiler switches or whatever is a can of worms. I would prefer that one of the clear genuine string types is used directly. Lots of code is dependend on the string type.

Agreed. As an intermediate solution MSEide+MSEgui uses interfaces in order to connect DB widgets with teditwidgetdatalink which communicates with standard TDataSource. So some of the code can be centralised. In order to implement extensions, bugfixes and workarounds MSEgui datasets have a tdscontroller property which also operates with interfaces.
I don't think that it is possible to develop a new DB framework based on a completely new approach in acceptable time frame because it needs a complete rewrite and would have zero or very low backwards compatibility. Remember how long it took until the current FPC DB implementation reached a usable state...

Martin

That's why you can set the mode for each unit or via a switch for each package/project.

Mattias

Thanks, Martin! Works beautifully, just what I needed.

Cheers,
David

That could as well be to not break old code, not to signify they both still have a place.

And I think shortstring should generally be discouraged. The standard is always "255 is enough", but sooner or later somebody hits it:

http://bugs.freepascal.org/view.php?id=15010

No, it should not be discouraged.

I, for one, use shortstring extensively, and have never "hit this limit" in 12 years of working, because I know when to use and when not to use a shortstring.

Shortstring has it's uses. It still works faster and uses less memory when used correctly. It also causes less memory fragmentation then.

Michael.

And I think shortstring should generally be discouraged. The standard is always "255 is enough", but sooner or later somebody hits it:

That's like saying that short integer types like byte or word should be discouraged and only Int64 should be used.

Shortstrings are just a completely different string type than ansistrings. Therefore it is dangerous to use the generic string type because in general a programer needs to know how the strings are stored, otherwise significant bugs are likely. With Shortsstrings you don't have to think about reference counters and other traps that can be cause hard to find errors (i.e. when using ansistrings within a highly nested data structure). Just think of a array of strings. If shortsstrings are used, all data is in one block of memory. You can move it around and make copies of it. But with ansistring this is not so easy. You only have an array of pointers. If you use move() on such an array then the reference counters are not affected and you get into trouble.

That's a different situation - extending a byte to an wider type is not a problem, done in the CPU every other tick.

Shortstrings are just a completely different string type than ansistrings.

That's it. Every string type must be handled differently by the RTL.

Therefore it is dangerous to use the generic string type because in general a programer needs to know how the strings are stored, otherwise significant bugs are likely.

NACK.

String handling procedures hide the details from the user, and they (have to) do their job well.

If you want to deal with the text (characters) in an string, you have to know much more about the string *encoding*. MBCS strings (UTF...) discourage at all the use of Char, and the use of indexed access to the characters in an string, regardless of the string *type*.

Dealing with strings at such an low level should not be required in everydays code. Leave it to the experts to implement TStrings, and work with the higher level methods. Your considerations apply as well to static and dynamic arrays of any type.

If binary data shall be kept in an string, then of course it's wise to use an specific type for such strings, which does no translations of the content. But then the contents should never be moved into other strings, but instead into variables of other types. The type should be something like ByteString or ByteArray, and that type should be incompatible with all other character strings.

DoDi

I think he means things like EAN codes (GS1-128 may have up to 48 characters), MD5 sums (32 characters) or some small piece of base64-encoded data. If you're ABSOLUTELY sure you will store only printable ASCII data (from 0x20 to 0x7e) and do not need more than 250 characters, ShortString may be useful.

2009/11/18 Hans-Peter Diettrich

Well, can be speed penalties on byte and word indeed.

Shortstrings are just a completely different string type than ansistrings.

That's correct.

Therefore it is dangerous to use the generic string type because in general a programer needs to know how the strings are stored, otherwise significant bugs are likely.

That goes for both shortstring and ansistring.

With Shortsstrings you don't have to think about reference counters and other traps that can be cause hard to find errors (i.e. when using ansistrings within a highly nested data structure).

No problem what so ever. ansistrings are safe unless you much in the internals on purpose.

Just think of a array of strings. If shortsstrings are used, all data is in one block of memory

(and on average 75% too large)

You can move it around and make copies of it. But with ansistring this is not so easy. You only have an array of pointers.

Assign them all of them, is a lot faster, since copy-on-write.

Seriously, there are basket cases where shortstrings are useful. But that was not what this is about. In the general case, you should avoid them.

Ptrint, but yes, as a measurement of variable length structures I think that is about right. Unless constrained by backwards compatibility.