Anders Melander

20 minutes ago, PhilPlus said:

So how to use the "offlien mode" ?

Read the documentation. Search for FireDAC offline

12 hours ago, Fr0sT.Brutal said:

Or any memory dataset. I believe Firedac has one

In principle, all FireDAC datasets are memory datasets. TFDMemTable is just a FireDAC dataset with no database connection.

FireDAC supports both "offline mode" and cached updates, so there's really no need to use TClientDataSet in this case.

However, it sounds as if the OP really just needs to set up the TFDQuery to fetch all data and then close the DB cursor.
Something like this:

Query.FetchOptions.Mode := fmAll;
Query.FetchOptions.AutoClose := True;

It's a hack. Go for the pragmatic solution instead; It's easier to maintain.

For something as simple as this it's simply not worth it to use an obscure hack that requires a 20 line comment explaining to your future self what the hell is going on and why it was necessary.

21 hours ago, plumothy said:

That looks interesting

When, in a few years, you or someone else comes across that code, "interesting" will not be the word used to describe it.

10 minutes ago, Ian Branch said:

Grep is exactly what I wanted.

Doesn't Search, Find in files do the same thing?

7 minutes ago, Vandrovnik said:

... and it tooks quite a lot of time to initialize. "Search for usages" also does just partial job when you doubleclick found item - it display the file, it selects found item, but cursor is off-screen, sou you have to press for exampe an arrow to see that place.

My guess is that it's using the same engine as the broken-beyond-repair refactoring tools (which afaik is implemented in J#, LOL)... It's incredible that they didn't remove this turd of a feature many, many, many years ago.

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Refactoring_Code

Quote

RAD Studio provides a set of refactoring operations that can help you re-architect your code in the most effective and efficient manner possible.

ROTFL

It's built right into the IDE. The only problem is that it seldom works 😞

[Edit: This is what @Pat Foley wrote about]

Right-Click and select Search for usages...

or right-click and select Find, Find local references to...

...or without the temporary buffer:

function ComputerName: string;
begin
  var Size: Cardinal := 0;
  if (not GetComputerName(PChar(Result), Size)) and (GetLastError <> ERROR_BUFFER_OVERFLOW) then
    RaiseLastOSError;
  SetLength(Result, Size-1);
  if (not GetComputerName(PChar(Result), Size)) then
    RaiseLastOSError;
end;

2 minutes ago, Jaska said:

This ID shifting is very annoying, but I guess it is very difficult the prevent it unless Delphi compiler starts caching the name-id maps.

It's unavoidable. For instance if a resourcestring is deleted then the whole range of IDs above it must change their ID. With regard to Windows resources I don't think ordinal resource IDs (not just string IDs) were ever meant to be stable. Instead we were supposed to use .rc and .h files and symbolic names - which is basically what the drc file is.

18 minutes ago, Jaska said:

It only works if the resource string IDs in both 32-bit and 64-bit EXE are exactly the same. This is not the case on most Delphi application.

Good point.

Luckily it's just the numeric ID values that change and these values aren't even guaranteed to be stable across compiles within the same platform. This is why BTM (and I'm guessing Soluling too) use the resourcestring names instead of the ID values to identify the strings.

The DRC file contains the mapping between name and ID value and this file is used when scanning the source application and when building the resource module DLL. So in order to build a resource module for a particular platform, you just point the build tool to the exe and drc of that platform and you will get a resource module that matches them.

Thanks for the kind words. Much appreciated.

1 hour ago, DxDublin said:

First the form preview.

Yes, I made a conscious choice not to include any kind of form editor or preview, even though I have these features implemented locally, simply because they never work reliably.

The main problem is that in case your forms contains 3rd party controls, then the viewer/editor will need to be able to load the runtime packages containing these controls, and the packages have to be the correct version, for the correct version of Delphi. etc. etc. It's a nightmare.

For in-house translation, I think I came up with a better solution to providing context. With a few lines of code one can have BTM follow the focus of the target application. Start the target application, open a form in the application and BTM will automatically select the corresponding module. Click a control in the application and BTM will select the properties of that control.

Of course with external translators providing the application, and all the dependencies it might have, might not be feasible (it isn't in our case). In that case a simple screenshot should do it.

1 hour ago, DxDublin said:

Second is that if you have both 32-bit and 64-bit applications, you need to create two separate projects and somehow copy paste the translations.

No need for that. The language modules, as @aehimself said, are just empty resource DLLs with no code. The same DLL stub is used for 32- and 64-bit.

1 hour ago, DxDublin said:

In addition, it scans all strings properties and you have to exclude them manually. There are no rules to configure what properties to localize and what to ignore.

Sure there is; It's called a Stop List. You can configure properties or modules to ignore based on a plethora of different rules - or regex if everything else fails.

2 hours ago, DxDublin said:

BTM has some translations aids but lots of features are missing, such as translation validation and interactive TM/MT/terms.

Validation is performed live. In addition, you can validate the whole project via the ribbon:

BTM validates a host of different properties such as leading and trailing space/colons/whatnot, delimiters, shortcuts, case (and type of casing), etc. etc. Many validation violations can be resolved automatically. Some are too risky to try and do automatically.

I don't know what you mean by "interactive TM/MT/terms". If you mean automatic translation lookup and prompt, then BTM does that too. The UI sucks a bit though.

2 hours ago, DxDublin said:

My test sample contains TTreeView and TListView components

Yes, these are Windows common controls and unfortunately, the VCL developers chose to persist them using their internal binary (and undocumented) stream format. If you look at the DFM file of a form containing one of these controls you will see what I mean.

I guess I could write adapters specifically for these controls but so far I haven't had any requests for them.

5 hours ago, Lars Fosdal said:

We went from ADO to FireDAC and significantly improved the performance.

Ditto. And ditto on your options.

20 hours ago, mario.arosio@gmail.com said:

Have you got any advice about the better set up?

Before trying to solve this problem you should determine where your bottleneck is instead of guessing. Is it the DB server, the network, the middleware (FireDAC), or your own code?

Examine the CPU, network usage, and DB server (using the activity monitor) during execution. Who's waiting on what? Profile your application or, if you don't know how to do that, just repeatedly pause your application in the debugger and examine the call stack. Chances are that the bottleneck will be somewhere in the call stack. It's a poor man's sampling profiler.

22 minutes ago, Rafael Dipold said:

no programs running in the background

You might not have started anything manually but there are always programs running in the background. This isn't DOS after all.

I would suggest you run a virus scanner on that system ASAP. My guess is that "something" has hooked into the clipboard chain and is corrupting the clipboard.

If the list contains CF_UNICODETEXT then it should also contain CF_TEXT because the clipboard internally synthesizes between the two formats automatically. It is impossible to only have one of them on the clipboard.

I would start by examining what it is you put onto the clipboard. You can use a simple clipboard viewer for this but it needs to be able to display the data as hex to be of much use.

The Drag and Drop Component Suite has a Drop Source Analyzer application that can do it. If you're brave you can use the one I have attached.

SourceAnalyzer.zip

https://bitbucket.org/anders_melander/better-translation-manager/src/master/Source/amProgress.API.pas

and another, slightly older, version of the same:

https://bitbucket.org/anders_melander/dwscriptstudio/src/master/Source/amProgress.pas

and even a DWScript wrapper (the second & third screenshots are actually from a DWScript):

https://bitbucket.org/anders_melander/dwscriptstudio/src/master/Source/ScriptRTL/amScriptModuleUserInterfaceProgress.pas

• Displays a non-modal form with a progress bar, a status message, and an optional cancel button.
• Defer the initial display of the progress form (what you call lazy loading). Default delay is 500 mS.
• Limit rate of progress update to minimize UI overhead. Default is max 1 update per 100 mS.
• Selectively pumps message queue to avoid application freeze and enable user to move/cancel progress dialog during use.
• Progressive or marquee mode.

The current implementation uses DevExpress label and button controls but these can just be replaced with regular VCL controls without any loss of functionality.

Usage:

var Progress := ShowProgress('Hello world', False);
Progress.EnableAbort := True;

Progress.Progress(psBegin, 0, 100, 'Charging flux capacitor...');

for var i := 0 to 100 do
begin
  Sleep(100);
  Progress.AdvanceProgress;
end;

and in Marquee mode:

var Progress := ShowProgress('Hello world', False);
Progress.EnableAbort := True;
Progress.Marquee := True;

Progress.UpdateMessage('Charging flux capacitor...');

while (not Progress.Aborted) do
begin
  Sleep(100);
  Progress.AdvanceProgress;
end;

2 minutes ago, Der schöne Günther said:

With Delphi 11.1, my actual output is exactly what you expect.

Thanks very much. Works in Delphi 11.0 too it seems.

This was driving me absolutely crazy because I was so sure that it wasn't a problem anymore but I just couldn't get it working. Some of my projects are in Delphi 10.3 and some are in 11.0 so that explains the confusion. I'll bet that in a year or so I will be in this situation again but at least there's a chance I will find this thread then 🙂

Once again I'm struggling with the fact that the compilers Return Value Optimization of interfaces produces code that keeps interfaces alive beyond the scope of the block in which they are referenced.

For example let's say that I have a function CreateFoo that creates a reference counted object and returns an interface to this object:

begin
  var Foo := CreateFoo;
  ...
  Foo := nil;
  ...
end;

One would think it was reasonable to assume that, given no other references to the object besides the Foo variable, once I nill the Foo reference then the reference count goes to zero and the object is destroyed. Right?... Nope.

It seems that what the compiler actually produces is something like this:

var
  Gotcha: IUnknown;
begin
  Gotcha := nil;
  try
    begin
      Gotcha := CreateFoo;
      var Foo := Gotcha as IUnknown;
      ...
      Foo := nil;
      ...
    end;
  finally
    Cotcha := nil;
  end;
end;

Since this is an old, known problem I wonder if anyone has been able to come up with a work around.

I have mostly been able to work around it in my own code by simply not relying on reference counted objects being destroyed inside local blocks but I have a few places where I simply either have to make this work properly or abandon reference counting.

FWIW, the following reproduces the problem:

program FooFail;
{$APPTYPE CONSOLE}
{$R *.res}
uses
  Classes;

type
  TFoo = class(TInterfacedObject)
  public
    constructor Create;
    destructor Destroy; override;
  end;

constructor TFoo.Create;
begin
  inherited Create;
  WriteLn('  Create');
end;

destructor TFoo.Destroy;
begin
  WriteLn('  Destroy');
  inherited;
end;

function CreateFoo: IUnknown;
begin
  Result := TFoo.Create;
end;

begin
  WriteLn('Begin');
  begin
    var Foo1: IUnknown := TFoo.Create;
    Foo1 := nil; // Foo1 destroyed here
  end;

  begin
    var Foo2: IUnknown := CreateFoo;
    Foo2 := nil;
  end;
  WriteLn('End');
end. // Foo2 destroyed here

The expected desired output is:

Begin
  Create
  Destroy
  Create
  Destroy
End

The actual output is:

Begin
  Create
  Destroy
  Create
End
  Destroy

Run the application in the debugger and when the dialog appears, pause the application in the debugger. You should then be able to examine the call stack in order to determine exactly where in the code the dialog is shown.

8 hours ago, pcoder said:

Also, not to forget the existing large number of functions with extended precision, most notably amath.pas

Sorry to hijack the topic but:

1. Wow! I had completely forgotten about that gem of a library.
2. There's a Double version to ease the transition: damath.pas
3. Can someone explain the following from the readme for me:

   Quote

   Note for FreePascal users: The 3.x versions support a new optimization level -O4 (-O3 + optimizations which might have unexpected side effects).
   For AMath/DAmath the so-called FASTMATH optimization is relevant:
   Among others floating point division by constants may be replaced by multiplication with the inverse, leading to quotients which are sometimes not correctly rounded!
   This obviously conflicts with the design goal of accurate computing and I recommend to turn off this feature using {$OPTIMIZATION NOFASTMATH} or with command line option -OoNOFASTMATH!

   Why aren't they correctly rounded? I ask because it's an optimization technique I use a lot.

5 hours ago, dummzeuch said:

If Google or Apple say their SDK requires Windows 10, how can Embarcadero say, Delphi will not?

Fair enough; Then state that these platforms requires Windows 10.

2 minutes ago, Uwe Raabe said:

At least one cannot rule out that.

Yes, we can't rule it out. My point was that they should be able to unless their developers are a bunch of cowboys.

2 minutes ago, Uwe Raabe said:

That's probably the reason why the don't include Windows 8.1 as a supported platform.

I'm not sure I understand what you mean. Do you mean that there are dependencies which requires Windows 10?

I could understand if they explicitly excluded support for Windows 8.x since it's probably impossible to find anyone running that of their own free will.

I haven't installed 11.2 but I haven't had any problems with prior versions and I'm running Windows 7...

1 hour ago, Uwe Raabe said:

How do you know that the IDE will still work in such an unsupported environment when all possible options are installed?

Because they know if they introduced new dependencies (at least they should know). And presumably they have beta testers using these environments.

6 hours ago, Tommi Prami said:

To me quite the opposite, just the release we needed. Quality updates should come more frequently IMHO.

Definitely. It's not that some of the things that are in the release isn't nice but given the fact that this major release is a year old today I guess I just expected something more. If there had been a roadmap I wouldn't have had these apparently unrealistic expectations.

Anyway, it is what it is. No big deal - yet.

Remember back in the day when a new release made you go Wooo Hooo ?

This release? Meh

You could probably have used the MSSQL Server Profiler to determine what the server is doing when you run the query.

With regard to transactions, I always use explicit transactions.

BeginTransaction;
try
  DoStuff;

  CommitTransaction;
except
  RollbackTransaction;
  raise;
end;