Leaderboard

Has anyone heard any more about this yet? The dreaded 1st August deadline is 3 weeks away after which we won't be able to give our Android users app updates should we need to. If things are running according to the last roadmap at EMB, then they're behind and haven't even released 10.3.2 yet let alone the sorely needed 10.4 which is supposed to contain the Android 64 bit work. I'm getting very worried that we might not be able to support our Android users for 3 months while they get a 10.4 beta out. We have 220,000 of them and the thought of not being able to get even an emergency bug fix to them should we need to terrifies me! Surely EMB must be taking this deadline seriously?

I filed a feature request for a new sort option to normalize the code while sorting.

I've heard if you have a libunity.so in your APK or your project name is unity (so it generates libunity.so) then Google accepts it as a 32bit Unity app. YMMV.

No, GExperts can't (because nobody answered that question yet).

Well i was on updating the FastCode "RTL replacement" then. Anyhow that is not my point, if you want to be the leader be my guest! My point is that all these years after FastCode nothing else is done and Microsoft has already made .Net Core open source. At least to me it's a start man to motivate your minds! I'll start to work moving the old FastCode code into this new project and on new Benchmark and Validation tools (on my free time), just follow the repository to see updates. That's all i can do for now. Thank you

Guys, are all of you missing this? Due to the Pascal calling convention, the first (plain!) argument of a function maps into the same register(s), so in fact this is valid and correct code. Though strictly I agree it looks weird and like as if in 'normal' cases the Value members aren't assigned to Result members. Bit in fact, they're already there! So what is actually needed is a 'type size limiting' cast, which is exactly what Result.x:=SmallInt(Result.x); is.

function IsFileInUse(FileName: TFileName): Boolean;var HFileRes: HFILE;begin Result := False; if not FileExists(FileName) then Exit; HFileRes := CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); Result := (HFileRes = INVALID_HANDLE_VALUE); if not Result then CloseHandle(HFileRes);end;procedure TForm1.Button1Click(Sender: TObject);begin if IsFileInUse('c:\Programs\delphi6\bin\delphi32.exe') then ShowMessage('File is in use.'); else ShowMessage('File not in use.');end;

After a while ... Thanks for the reply @Andrea Magni. I think I'll follow your guidelines.

You will need to manually call TBindings.Notify because your controls are not observable: http://docwiki.embarcadero.com/RADStudio/Rio/en/Tutorial:_Creating_LiveBindings-Enabled_Components As to why even manual call does not work, it is hard to tell without compilable demo.

1. I already have this in my design plans but it seems i can not host a database on the Github so currently i'll have to use my personal hosting. 2. Thanks! I'll contact him after Benchmark/Validation apps are made.

A further thought: Perhaps a command to normalize without sorting class(es)? Resorting the classes would make for some source control issues in future. The normalization of signatures, though it would obviously affect source control, would be relatively minor, by comparison.

I have a plan to start with 64bit development in a few months, so I will definitely be available to contribute with testing, bench marking, if needed.

I would consider this to be a Stone Soup. So with minor contributions from everyone, this could really be a great thing. It could of course also go the way quite a few open source projects have gone straight towards oblivion, but I tend to look at things positive. I would be happy to contribute "human readable" content such as installation instructions (something lacking in most other OS projects) and so forth.

AFAIK, that won't work. As an alternative you can use the built in Delphi code format feature with <Ctrl>-D.

Updated version. Takes two params. First is the path of the app to run and the second is the port to run it on. Apparently balance only supports 16 (or 32) groups unless you compile it yourself. Example: ./gtkcloud.sh /root/FireMonkeyPaintDemo 81 #!/bin/bash for i in {1..16} do nohup broadwayd :$i & export GDK_BACKEND=broadway export BROADWAY_DISPLAY=:$i $1 & #echo "" done servers="" for ii in {1..18} do let port=8080+$ii servers="$servers localhost:$port:1 %" done echo $servers balance $2 $servers

You might want to do a survey to confirm your speculation on how many developers are still on 32-bit vs 64-bit. I'd be surprised if even 25% of Delphi users are on 64-bit.

Well, we already have the Current RTL for benchmarking. I'll see what i can do tranfering the old FastCode pascal to this project

Hi @Stuart Clennett, I am happy you found a way to solve by yourself while I was in vacation 🙂 Your solution works but has a couple of things to consider: 1) that BeforeHandleRequest code gets executed for each incoming request (performance) 2) manipulating Parameters is not suggested as App.Parameters is like a global object (IIRC). You have an other opportunity through (yet another) undocumented MARS feature: [Context, Connection('Dynamic_MyConnection', True)] FD: TMARSFireDAC; The Connection attribute specifies the name of the connection definition to be used with the TMARSFireDAC instance injected. The name supports macros (the second argument enables macro expansion). You can rely on built-in macros (i.e. using some part of the token, params, username or similar things. A list is available here: https://github.com/andrea-magni/MARS/blob/a8d323558bd591589ef667eac326324302d167a9/Source/MARS.Data.FireDAC.pas#L528 ). Last chance of the macro-expander is looking for custom providers. You can register your own in the initialization of one of your units or in the Server.Ignition.pas file: TMARSFireDAC.AddContextValueProvider( procedure (const AActivation: IMARSActivation; const AName: string; const ADesiredType: TFieldType; out AValue: TValue) begin if SameText(AName, 'Dynamic_MyConnection') then begin if Odd(SecondOf(Now))then AValue := 'OddConnection_' + AActivation.Request.HostName else AValue := 'EvenConnection_' + AActivation.Request.HostName; end; end ); Beware: the connection name has to be this format: [PREFIX]_[SUFFIX](_[OTHER_SUFFIX]) Using 'MyConnection' won't work for instance... Pros of this approach: 1) code is executed only when needed (when the TMARSFireDAC instance gets created to be injected in your resources), all others REST endpoints won't be affected. 2) it seems more isolated to me (but this can be a personal evaluation). If you need to fix some TFDConnection instances on your datamodules, try having a TMARSFireDAC instance injected in the datamodule itself and use the FD.ConnectionDefName (already expanded once injected) to fix the ConnectionDefName of your components (OnCreate event of the datamodule should be fine, or AfterConstruction method as well). If you encounter troubles doing this, write here again: there's another hidden feature for you to fix this (when registering the datamodule as resource you can specify an anonymous method to initialize it or to call a custom constructor instead of TDatamodule.Create(AOwner)). Sincerely, Andrea

I mentioned that I am working on the Delphi Tools Manager in my post about GExperts supporting import and export for the Tools menu. Today I finished the first version of this tool. It supports all Delphi versions from 5 to 10.3 (it is written in Delphi 10.2). So, what does it do: It shows a list of all entries in the Delphi IDE’s tool menu in a similar manner as the Tools Options dialog. It allows the same actions as that dialog: Add/Delete/Edit an entry and change the order of the entries. It shows the details of each entry when it is selected. It allows exporting and importing entries, using the same DTME file format as GExperts Dragging one or more DTME files on the form will add them to the list Read on in the blog post at https://blog.dummzeuch.de/2019/06/16/delphi-tools-manager-1-0-0-released/

The Delphi IDE has the quite useful option to add custom entries to the Tools menu. These entries call external programs with some “Macros” that reference the current IDE status, e.g. the currently active project or source file and some of their properties like the output directory or the current editor column and row. GExperts already enhances the Tools Properties dialog by adding auto completion for the file name and the working directory (for Delphi 6 and 7 it also adds support for Drag and Drop, but that doesn’t work for later versions). It has always irked me that there was no easy way to port these custom tools entries from one Delphi version or installation to another. I always had to copy and paste four fields to achieve that. GExperts now adds two new buttons to export and import the current entry: Read on in my blog post https://blog.dummzeuch.de/2019/06/08/new-gexperts-ide-enhancement-export-and-import-entries-for-the-tools-menu/

"...a single Language Server can be re-used in multiple development tools, which in turn can support multiple languages with minimal effort." In theory it would divorce the Delphi language from the Delphi IDE. This would allow for Delphi code completion and other features to be accessed from tools such as VS Code, Eclipse, Sublime Text and anything else implementing the protocol and enable supporting additional languages in the Delphi IDE. In theory. I can't shake the feeling that Embarcadero will find some way to lock things down. But the idea is really great and I've been advocating for this since the concept was first revealed by Microsoft and Red Hat.

@PeterBelow Thank you what i did in the above program just added 2 lines findexpl:=GetAncestor(WebBrowserApp.HWnd,GA_ROOT); SetForegroundwindow(findexpl);

At least it's better than non-existence.

I have done an intensive debug session and found the issue although I don't understand why it works with older Delphi versions. At line 2710, where the server hang, we have the code: Result := GetOverlappedResult(FPipe, FOlapRead, FRcvRead, TRUE); I simply changed the last argument by FALSE like this: Result := GetOverlappedResult(FPipe, FOlapRead, FRcvRead, FALSE); And now it works! That last argument when TRUE tells GetOverlappedResult to wait until completion. If FALSE, it returns immediately with whatever data is available, setting FRcvRead variable with actual number of bytes read. Since we only go to that code line when data is available, because of WaitForMultipleObjects called at line 2939, we can safely don't wait for more data. I will do more testing with the actual - real world - application using that code. In case the issue persist, I will report it here. Thanks to all having participated in this conversation. -- François Piette Embarcadero MVP

That's the name of the executing process. Asker wants to know about external processes.