dummzeuch

1 hour ago, Stalker4 said:

As you advised, I compiled a new dll from the sources, but there was an error that I wrote about here and about which. I also wrote on “sourceforge” it is not corrected there. .

I'll be on vacation. Maybe I will find some time to look into this.

1 hour ago, Lajos Juhász said:

Also until developers did not start to use multiple languages.

I have never ever confused Pascal Strings with C char* types. (And I have done quite a lot C programming at the beginning of my career, parallel to using Turbo Pascal and Visual Basic, before I chose Delphi as my main programming tool.)

3 hours ago, David Heffernan said:

I don't disagree with that point. My point is that it was a bad idea in the first place to make strings 1 based.

Depends. Back then (in the 1970ies *1) it made a lot of sense to store strings that way. And when moving from Pascal to Delphi (>20 years later) and introducing longstrings (Delphi 2?) it already was a decision between keeping backwards compatibility to Pascal vs. being compatible with C.

Edit: (*1: I'm not sure when strings were introduced into Pascal: Was it an addition in Turbo Pascal (1986) or did they already exist in the original Pascal?)

Since Delphi is kind of a legacy programming language nowadays, backwards compatibility is very important. You don't want to throw away millions lines of proven code because they don't work any more, or even worse, because they are now buggy. So trying to change strings to be zero based was a bad idea, even if it was "just for mobile platforms".

1 hour ago, David Heffernan said:

You can for short strings

Oh, yes, I had totally forgotten about short strings. And also about that stupid idea of making strings zero based.

5 hours ago, David Schwartz said:

Aside from that, did you get anything from reading the post? (I don't have a compiler in my head, and I figured if I didn't show the declarations then someone would ding me on that.)

My point is that you can't declare variables or types like this in Delphi. This is C like syntax. In Delphi you have to give a low and a high limit for an array. So at least you don't have to guess.

8 hours ago, David Schwartz said:

Considering Delphi:

 

Given this declaration: var ary[10] : char; str[10] : string;

[dcc32 Error] Project1.dpr(10): E2029 ',' or ':' expected but '[' found
[dcc32 Error] Project1.dpr(10): E2029 '(' expected but ';' found
[dcc32 Error] Project1.dpr(10): E2029 Expression expected but ';' found
 

1 hour ago, Cristian Peța said:

If not multi threading then it can be.

We are talking about a DLL here, so your code might not be multithreaded, but the caller's still might be.

18 minutes ago, Cristian Peța said:

procedure Foo; stdcall;
begin
  SetFPCR;
  ...
  RestoreFPCR;
end;

Do you think is so cumbersome to do this for every exposed function?

The SetFPCR and RestoreFPCR you need to write for yourself but only once.

And for convenience, use a global variable to store the state ... gd&r

I don't know whether it fits your definition of "good", but I have got:

https://sourceforge.net/p/dzlib/code/HEAD/tree/dzlib/trunk/src/u_dzIso8601.pas

and

https://sourceforge.net/p/dzlib/code/HEAD/tree/dzlib/trunk/src/u_dzDateUtils.pas

1 hour ago, JonRobertson said:

Hopefully not with 

 

Shift-Alt-W (MMX Convert with statement) is a good friend of mine when "migrating" legacy Delphi code.

Even with has its uses. 

But a convert tool that can remove them sounds really interesting. Is that part of Uwe's MMX explorer?

1 hour ago, Brandon Staggs said:

And no, not "just because you can." "Just because you can" doesn't pay the bills.

Actually, in my case it sometimes is "just because I can". I use Delphi not only to pay my bills, sometimes I just want to have some programming fun, and I imagine I'm not alone.

But yes, there are actual reasons to use features in Delphi that are frowned upon by some people, even the discouraged goto.

33 minutes ago, Wagner Landgraf said:

That's the mystery, isn't it?

First, thanks a lot for the detailed test.

 

So let me try to summarize what you found out: in Release config, even if you check "Debug Information" option to True (in Project Options, Building | Delphi Compiler | Linking), it doesn't generate line number, unless you explicitly add the `{$D+}` directive in the source code, is that correct?

 

If yes, I think finding out the reason might explain what's happening here.

For the record, I'm using *Debug* config, and "Debug Information" is set to True. But still, I can't get line numbers. So maybe what's happening in my Debug config is the same as it's happening in your Release config?

I suggest you make your own tests with a simple project to check how the compiler / linker options behave with regards of adding line numbers to the map file. There may be more options that affect it.

I just tested a program in Delphi 10.2 and got the following call stack:

Exception at [0092DF9A] w_SigAbout.Tf_SigAbout.Execute (Line 79, "w_SigAbout.pas"):
Test
<begin call stack>
[0092DF95] w_SigAbout.Tf_SigAbout.Execute (Line 77, "w_SigAbout.pas" + 3) + $11
[0093D548] w_AnonymisierungRestApi.Tf_AnonymisierungRestApi.act_GetProgramInfoExecute (Line 2055, "w_AnonymisierungRestApi.pas" + 1) + $8
[004D0C0B] System.Classes.TBasicAction.Execute (Line 16901, "System.Classes.pas" + 3) + $7
[0052FE8A] Vcl.ActnList.TCustomAction.Execute (Line 260, "Vcl.ActnList.pas" + 19) + $35
[004D0A77] System.Classes.TBasicActionLink.Execute (Line 16812, "System.Classes.pas" + 2) + $7
[0060339B] Vcl.Menus.TMenuItem.Click (Line 2539, "Vcl.Menus.pas" + 17) + $7
[00604AFC] Vcl.Menus.TMenu.DispatchCommand (Line 3482, "Vcl.Menus.pas" + 5) + $4
[00605D8E] Vcl.Menus.TPopupList.WndProc (Line 4655, "Vcl.Menus.pas" + 4) + $E
[00605CDD] Vcl.Menus.TPopupList.MainWndProc (Line 4630, "Vcl.Menus.pas" + 2) + $5
[004D1970] System.Classes.StdWndProc (Line 17405, "System.Classes.pas" + 8) + $0
[0061E18B] Vcl.Forms.TApplication.ProcessMessage (Line 10641, "Vcl.Forms.pas" + 23) + $1
[0061E1CE] Vcl.Forms.TApplication.HandleMessage (Line 10671, "Vcl.Forms.pas" + 1) + $4
[0061E501] Vcl.Forms.TApplication.Run (Line 10809, "Vcl.Forms.pas" + 26) + $3
[0095195D] Anonymisierung.Anonymisierung (Line 36, "" + 4) + $7
<end call stack>

As you can see there are line numbers for the system units as well as for the ones of the program.

This is from the debug build.

But, if I compile with the release configuration, I get the following:

Exception at [0090B884] w_SigAbout.Tf_SigAbout.Execute:
Test
<begin call stack>
[0090B87F] w_SigAbout.Tf_SigAbout.Execute + $37
[0091AC2B] w_AnonymisierungRestApi.Tf_AnonymisierungRestApi.act_GetProgramInfoExecute + $7
[004D0763] System.Classes.TBasicAction.Execute + $F
[0052F88E] Vcl.ActnList.TCustomAction.Execute + $86
[004D05CF] System.Classes.TBasicActionLink.Execute + $13
[00602D77] Vcl.Menus.TMenuItem.Click + $93
[006044D8] Vcl.Menus.TMenu.DispatchCommand + $18
[0060576A] Vcl.Menus.TPopupList.WndProc + $82
[006056B9] Vcl.Menus.TPopupList.MainWndProc + $1D
[004D14C8] System.Classes.StdWndProc + $14
[0061DB67] Vcl.Forms.TApplication.ProcessMessage + $F3
[0061DBAA] Vcl.Forms.TApplication.HandleMessage + $A
[0061DEDD] Vcl.Forms.TApplication.Run + $C9
[0092E77D] Anonymisierung.Anonymisierung + $49
<end call stack>

As you can see, there are no line numbers, neither for system units nor for the ones of the program. I could have sworn it should have worked. The configuration for the map file is identical in both.

If I change the configuration to use debug dcus, I get line numbers for the system units:

Exception at [0090B87C] w_SigAbout.Tf_SigAbout.Execute:
Test
<begin call stack>
[0090B877] w_SigAbout.Tf_SigAbout.Execute + $37
[0091AC23] w_AnonymisierungRestApi.Tf_AnonymisierungRestApi.act_GetProgramInfoExecute + $7
[004D075B] System.Classes.TBasicAction.Execute (Line 16901, "System.Classes.pas" + 3) + $7
[0052F886] Vcl.ActnList.TCustomAction.Execute (Line 260, "Vcl.ActnList.pas" + 19) + $35
[004D05C7] System.Classes.TBasicActionLink.Execute (Line 16812, "System.Classes.pas" + 2) + $7
[00602D6F] Vcl.Menus.TMenuItem.Click (Line 2539, "Vcl.Menus.pas" + 17) + $7
[006044D0] Vcl.Menus.TMenu.DispatchCommand (Line 3482, "Vcl.Menus.pas" + 5) + $4
[00605762] Vcl.Menus.TPopupList.WndProc (Line 4655, "Vcl.Menus.pas" + 4) + $E
[006056B1] Vcl.Menus.TPopupList.MainWndProc (Line 4630, "Vcl.Menus.pas" + 2) + $5
[004D14C0] System.Classes.StdWndProc (Line 17405, "System.Classes.pas" + 8) + $0
[0061DB5F] Vcl.Forms.TApplication.ProcessMessage (Line 10641, "Vcl.Forms.pas" + 23) + $1
[0061DBA2] Vcl.Forms.TApplication.HandleMessage (Line 10671, "Vcl.Forms.pas" + 1) + $4
[0061DED5] Vcl.Forms.TApplication.Run (Line 10809, "Vcl.Forms.pas" + 26) + $3
[0092E77D] Anonymisierung.Anonymisierung + $49
<end call stack>

If I also include debug information, I get line numbers for both, system and program units:

Exception at [0090B878] w_SigAbout.Tf_SigAbout.Execute (Line 79, "w_SigAbout.pas"):
Test
<begin call stack>
[0090B873] w_SigAbout.Tf_SigAbout.Execute (Line 77, "w_SigAbout.pas" + 3) + $11
[0091AC1F] w_AnonymisierungRestApi.Tf_AnonymisierungRestApi.act_GetProgramInfoExecute (Line 2055, "w_AnonymisierungRestApi.pas" + 0) + $7
[004D075B] System.Classes.TBasicAction.Execute (Line 16901, "System.Classes.pas" + 3) + $7
[0052F886] Vcl.ActnList.TCustomAction.Execute (Line 260, "Vcl.ActnList.pas" + 19) + $35
[004D05C7] System.Classes.TBasicActionLink.Execute (Line 16812, "System.Classes.pas" + 2) + $7
[00602D6F] Vcl.Menus.TMenuItem.Click (Line 2539, "Vcl.Menus.pas" + 17) + $7
[006044D0] Vcl.Menus.TMenu.DispatchCommand (Line 3482, "Vcl.Menus.pas" + 5) + $4
[00605762] Vcl.Menus.TPopupList.WndProc (Line 4655, "Vcl.Menus.pas" + 4) + $E
[006056B1] Vcl.Menus.TPopupList.MainWndProc (Line 4630, "Vcl.Menus.pas" + 2) + $5
[004D14C0] System.Classes.StdWndProc (Line 17405, "System.Classes.pas" + 8) + $0
[0061DB5F] Vcl.Forms.TApplication.ProcessMessage (Line 10641, "Vcl.Forms.pas" + 23) + $1
[0061DBA2] Vcl.Forms.TApplication.HandleMessage (Line 10671, "Vcl.Forms.pas" + 1) + $4
[0061DED5] Vcl.Forms.TApplication.Run (Line 10809, "Vcl.Forms.pas" + 26) + $3
[0092E77D] Anonymisierung.Anonymisierung (Line 36, "" + 4) + $7
<end call stack>

Comparing the map files shows that the Line numbers are mostly missing from the release configuration's map file. These are the line numbers for w_SigAbout from the debug build:

Line numbers for w_SigAbout(w_SigAbout.pas) segment .text

    74 0001:0050A83C    75 0001:0050A843    76 0001:0050A854    77 0001:0050A862
    79 0001:0050A878    80 0001:0050A882    82 0001:0050A89A    84 0001:0050A8AF
    89 0001:0050A8CC    90 0001:0050A8FF    91 0001:0050A910    92 0001:0050A91E
    93 0001:0050A928    94 0001:0050A933    96 0001:0050A94B    98 0001:0050A960
   107 0001:0050A98C   108 0001:0050A9C2   110 0001:0050A9CC   112 0001:0050A9D9
   113 0001:0050AA96   116 0001:0050AAAF   118 0001:0050AB98   120 0001:0050AC97
   121 0001:0050AD98   123 0001:0050ADB1   125 0001:0050ADB9   127 0001:0050ADC1
   129 0001:0050ADD8   130 0001:0050ADE0   131 0001:0050ADF2   133 0001:0050AE07
   134 0001:0050AE23   135 0001:0050AE30   136 0001:0050AE41   137 0001:0050AE4A
   138 0001:0050AE5D   139 0001:0050AE66   140 0001:0050AE6F   141 0001:0050AE78
   142 0001:0050AE91   133 0001:0050AE94   145 0001:0050AE99   146 0001:0050AEAA
   147 0001:0050AEB3   148 0001:0050AEC6   149 0001:0050AECF   150 0001:0050AED8
   156 0001:0050B0F0   157 0001:0050B108   158 0001:0050B127   159 0001:0050B13B
   160 0001:0050B13F   161 0001:0050B155   162 0001:0050B159   163 0001:0050B166
   169 0001:0050B1E0   170 0001:0050B203   171 0001:0050B211   172 0001:0050B232
   173 0001:0050B240   174 0001:0050B250   175 0001:0050B31C   176 0001:0050B32D
   178 0001:0050B346   179 0001:0050B35A   177 0001:0050B371   186 0001:0050B396
   187 0001:0050B47B   190 0001:0050B566   191 0001:0050B657   192 0001:0050B748
   193 0001:0050B839   194 0001:0050B92A   195 0001:0050BA1B   196 0001:0050BB0C
   198 0001:0050BC0A   201 0001:0050BC31   202 0001:0050BC64   203 0001:0050BD36
   204 0001:0050BD47   205 0001:0050BD57   206 0001:0050BD67   208 0001:0050BE29
   211 0001:0050C074   212 0001:0050C0B1   213 0001:0050C0C1   214 0001:0050C199
   215 0001:0050C271   216 0001:0050C349   217 0001:0050C421   218 0001:0050C4F9
   219 0001:0050C5E1   226 0001:0050C75C   227 0001:0050C762   228 0001:0050C772
   230 0001:0050C777   231 0001:0050C78C   230 0001:0050C7A1   232 0001:0050C7A4
   233 0001:0050C7C2   234 0001:0050C7C9   236 0001:0050C7D5

That section is completely missing from the release build, even though both are set to write a detailed map file.

So I guess it does matter whether the units are compiled with debug information turned on or off as apparently the linker cannot write the line numbers to the map file if the dcus do do not contain debug information. But that's not because jcldebug reads them from the dcus / executable but because the linker does.

Edit: I just confirmed that with an empty console application project created with File -> New -> Console Application

Turning on the detailed map file for Win32, comiling for debug and release and then comparing the map files:

There are line numbers for the debug configuration and no line numbers for the release configuration.

Turning on debug information for a unit like this:

unit Unit1;
{$D+}
interface

implementation

procedure Test;
begin
  WriteLn('bla');
end;

end.

Creates line number entries for that unit even for the release build:

Line numbers for Unit1(Unit1.pas) segment .text

    12 0001:00000000

Google found this:

http://docwiki.embarcadero.com/RADStudio/Alexandria/en/Linking

But turning this option on for the release build did not make any difference.

45 minutes ago, Wagner Landgraf said:

If that would be the case, it would not show line number information for Delphi units, isn't it? It's "modern" DCU. 

It just looks that Delphi DCUs have some additional information that my DCUs don't have, but I don't know what that would be.

Since the dcu file format is not documented, I doubt that jcldebug uses it to get line number information.

9 hours ago, Dave Nottage said:

In your unit, is there a debug info directive? i.e. if you have {$D-} or {$DebugInfo Off}, it will not include debug info.

Debug information has nothing to do with line numbers from jcldebug. Jcldebug only uses the map file for that.

I'm not that familiar with the inner workings, but what works for me for debug builds is turning on stack frames, turning off inlining and optimization and creating a detailed map file.

For release builds I only use that detailed map file. That gets me the line numbers in stack traces. 

BUT: My experience with that is still mostly based on Delphi 2007. It's possible that it does not work for later Delphi versions.

11 hours ago, Rick_Delphi said:

The reason I started using Delphi was the RAD approach. Now with no-code low-code being new buzzwords, where does Delphi stand on that front?

Nobody kehrs ( https://images.app.goo.gl/jtQZNqxjkAh559Do9 )

• People, who don't know Delphi, will not touch it.
• People, who like Delphi will continue to use it
• People, who use Delphi but don't like it (any more) will continue to use it until they find an alternative.

Any new buzzword bullsh*t will not change that.

To translate:

low code = RAD

no code = does not exist

18 minutes ago, FredS said:

Thought the point was for it to be better than the last system..

No. The point was that Atlassian has discontinued supporting on-premise servers and asked customers to migrate to the Atlassian hosted version, as said in the blog post announcing the migration.

18 hours ago, dkounal said:

What about Delphi 12.1 ?

I haven't installed it yet. Download is done though.

It's possible that the last Delphi 12.0 release works with Delphi 12.1, if not, you could try to compile your own DLL, until I get around to make a new release.

Fixed

27 minutes ago, JonRobertson said:

In Tools Options, after clicking "Add Defaults", I then deleted each of the items that were added. Except the Delete button does nothing when there is a single item in the list.

 That's because the last line of a string grid cannot be deleted. But the delete button should have cleared the line. If it doesn't, that's indeed a bug.

As mentioned in my previous post on dzDebugVisualizer I was thinking about writing a generalized debug visualizer which can be user-configured to register itself for any data type. Well, that debug visualizer now exists. It’s part of dzDebugVisualizer and called “Universal Visualizer for Delphi”.

Read on in the blog post.

Given a TStringGrid with

FixedRows = 1

FixedCols = 0

RowCount = 51 (50 data rows)

ColCount = 3

I want to configure the vertical scroll bar so that the thumb represents the part of the string grid that is visible relative to the full height.

I found an article on SwissDelphiCenter which gives the folowing code:

procedure TForm1.Button1Click(Sender: TObject);
var
  info: TScrollInfo;
begin
  FillChar(info, SizeOf(info), 0);
  with info do
  begin
    cbsize := SizeOf(info);
    fmask  := SIF_ALL;
    GetScrollInfo(StringGrid1.Handle, SB_VERT, info);
    fmask := fmask or SIF_PAGE;
    nPage := 5 * (nmax - nmin) div StringGrid1.RowCount;
    // whatever number of cells you consider a "page"
  end;
  SetScrollInfo(StringGrid1.Handle, SB_VERT, info, True);
end; 

As far as I understand this, it sets the thumb size to represent 5 rows.

I looked up the documentation of GetScrollInfo and SetScrollInfo and came up with a slightly modified version:

///<summary>
/// Sets the thumb of the scroll bar of a TStringGrid to represent the visible area relative to the full area.
/// @param GridHandle is the window handle of a TStringGrid
/// @param Which is either SB_VERT or SB_HORZ
/// @Param VisibleCount is TStringGrid.VisibleRows (for SB_VERT) or .VisibleCols (for SB_HORZ)
/// @param DataCount is number of non-fixed rows (for SB_VERT) or columns (for SB_HORZ) </summary>
procedure TStringGrid_AdjustScrollBarPage(_GridHandle: HWND; _Which: Integer; _VisibleCount, _DataCount: Integer);
var
  Info: TScrollInfo;
  Size: Integer;
begin
  Size := SizeOf(Info);
  ZeroMemory(@Info, Size);
  Info.cbSize := Size;
  Info.fMask := SIF_ALL;
  GetScrollInfo(_GridHandle, _Which, Info);
  Info.fMask := SIF_PAGE or SIF_RANGE;
  Info.nPage := _VisibleCount;
  Info.nMin := 1;
  Info.nMax := _DataCount;
  SetScrollInfo(_GridHandle, _Which, Info, True);
end;

(I can probably get rid of the call to GetScrollInfo, as I don't need the values of nMin and nMax to calculate nPage)

I call it in the form's Resize event like this:

TStringGrid_AdjustScrollBarPage(TheGrid.Handle, SB_VERT, TheGrid.VisibleRowCount, TheGrid.RowCount - TheGrid.FixedRows);

(Which sets nPage to 10, nMin to 1 and nMax to 50.)

And it seems to work ...

... at least visually. Unfortunately moving the thumb down to the bottom no longer shows the last lines of the grid:

(Remember: There are 50 data rows + 1 fixed row)

What am I doing wrong here? Is there some other value I need to adjust?

Edit: The culprit seems to be the code in TCustomGrid.ModifyScrollBar which calculates the new NewTopLeft value wrongly. Possibly because it makes some assumptions that are no longer true when the scrollbar parameters are set like this. So I either need to figure out a different way to set those parameters or handle the WM_VSCROLL message myself.

7 minutes ago, Sherlock said:

I feel you got a typo in your code, @dummzeuch 

	type
	  TNullableDateTime = record
	  private
	    FIsValid: INullableTypesFlagInterface;
	    FValue: TDateTime;
	  public
	    function Dump: string;
	    // other methods and operators
	  end;
	 
	// ...
	implementation
	// ...
	 
	function TNullableDateTime.Dump: string;
	begin
	  if IsValid then
	    Result := DateTimeToStr(Value)  // <- should be FValue?
	  else
	    Result := '<invalid>';
	end;

Should the Dump function not refer to FValue?

Value is a property which I have left out in the shortened type declaration. The same goes for the function IsValid, that checks if the field FIsValid is assigned. So, strictly speaking you are right, the example code won't compile. But the point was to show how to implement a Dump method in principle.

If you want to have a look at the actual imlementation of TNullableDateTime, see the unit u_dzNullableDateTime in the dzlib svn repositiory on SourceForge.

16 minutes ago, dormky said:

Does delphi output other intermediate files that I could check ?

Hm, maybe the map file?

Do you build dcu files containing debug information? If yes, the debug information contains a line number, so the size might change if the number of lines containing code changes. There might be other kinds of information in the dcu which are similarly affected. The dcu format isn't documented, but I remember a project on GitHub that could read them - at least get identifiers out of them - so maybe that project also contains some kind of documentation or at least parsing code that might shed some light on this.