Cristian Peța

1 minute ago, Uwe Raabe said:

BTW, you can even use Delphi when there is no connection to the ELC server for up to 30 days.

Delphi activated without ELC will run without internet connection indefinitely or this 30 days applies too?

1 minute ago, Uwe Raabe said:

You cannot. I just explained what can be done to be independent when that happens next.

It is not somehow similar to having Delphi installed into a VM?

If Delphi can call home then also ELC can call home at some point in time.

1 minute ago, Lars Fosdal said:

The downside of multiple Sleep + time checks to allow termination, consumes more CPU.

You are right.

I'm using Sleep() only in Windows services in the ServiceExecute(). 50 or 100 ms is not an issues for a service to get down. And checking Terminated, an increment and loop every 50 ms is nothing.

4 minutes ago, dormky said:

the code called by the timer is "fire and forget"

15 minutes ago, dormky said:

If it's on the main thread, it runs the risk of getting delay by other work (namely, heavy drawing). If the timer is delayed, the event is delayed too.

Use Sleep() in the thread and start other threads at that interval.

The thread with the Sleep() will need to have highest priority.

If you have a timer there is a possibility that your execution will not end and a new one will need to be started.

With Slepp() this can not happen.

1 minute ago, dormky said:

Anyone have a recommendation for a TTimer equivalent that has its callback executed in the thread it was created in ?

What is wrong with Sleep()

Into the Execute you need to have a code that will not exit till you need that thread alive.

procedure TMyThread.Execute;
var
  LHowMuchToWait: Integer;
  LDoExit: Boolean;
begin
  try
    repeat
      ExecuteMyClass(LHowMuchToWait, LDoExit);
      Sleep(LHowMuchToWait);
    until LDoExit or Terminated;
  finally
    Terminate;
  end;
end;

Now I see that FieldData can be defined for max 256 fields.

    FieldData: array [0..255] of PAnsiChar;

And get rid of setting the length of FieldData for every field.

uDBF.pas

Sorry, uploaded wrong file...

uDBF.pas

1 hour ago, Mark- said:

What is "dragon4"?

I suppose is about the algorithm (google for "Dragon4 algorithms").

I used FieldData array to store offsets instead of FData that must remain 4 bytes.

Maybe there are better approaches but it was faster so.

This is a fast patch and not optimal.

uDBF.pas

It is working like compiled in D11.1 if you disable ASLR from linking options.

    FData : DWORD;

And should be 8 bytes on 64 bit. Something like PAnsiChar.

        Fields^[iFieldCount].FData := DWORD(Data + iTmp);

It is wrong to cast to DWORD for 64 bit.

Do you have thousand record types? Then you have some work...

If there are not so many record types and you need to use both 32 and 64 bit versions then I would make for every record an old version that has Cardinal instead of pointer just for reading from and writing to the stream.

And two procedures to copy data between old and new record.

The old record with Cardinal will be used only to stream data.

If you want to do more then use old records with Cardinal instead of pointer only for reading. And save data in a new format like JSON.

4 minutes ago, Navid Madani said:

The size of string fields needs to be set?

ftString size is default to 20. If you want not to set the size then you can use ftMemo.

Intel VTune with map2pdb

With pointers like Alexander suggested or an array or records.

If someone do have an issue that is possible solved in latest commit why not trying?

I can't think that an commit is made without testing first.

1 hour ago, msd said:

There is v5.05 on official GitHUB Channel (release date is 25.06.2023 do you have some fresh info

Have you checked https://github.com/pleriche/FastMM5/activity?ref=master ?

Latest commit is 6 nov. "Handle a potential race condition in FastMM_DetectClassInstance: If another thread frees a block while it is being evaluated as a potential class then an A/V could occur. This indirectly affects other functionality, like FastMM_LogStateToFile."

You can download sources if you don't use git to clone repository: https://github.com/pleriche/FastMM5/archive/refs/heads/master.zip

Windows or something else?

You can try to delete .dproj and see if that helps.

15 minutes ago, Marcelo Bernardi said:

edit1.text := 'TEXTO TESTE';

This is all we need to reproduce?

Can you reproduce in a small test project?

33 minutes ago, Juan C.Cilleruelo said:

Arm technology allows, with the same batteries, more than 20 hours between charges, for example. 

Arm technology allows a much more power computation, without consuming more energy. 

 

Really do you think that the future is Intel architecture? 

Or do you think that Intel is ready to create processors without these limitations? 

Personally I wouldn't buy Windows ARM because incompatibilities. 20 hours without charge is nice but is not a must have for me.

1 hour ago, Juan C.Cilleruelo said:

Since Apple is embracing ARM architecture, Microsoft is still waiting to no one know what, while in the field of hardware, the technology was ready a time ago. 

Apple is giving you no choice. With Windows people can choose and there are not so many eager to embrace this change.

Maybe I'm wrong, but CopyDataSet doesn't use ArrayDML. Only if speed matters.

Probably something went wrong with first attempt to recreate dproj file.

I tried again to delete it and now debugging works for x64.