Leaderboard

I know there isn't but Idera really should think about adding one.

Perhaps this gives an idea. https://chapmanworld.com/2017/04/06/calling-linux-commands-from-delphi/

Ok, so today I received an email from the reseller and EMBA has bumped the license

I guess you could modify DefFontData in a design time package

Lazarus has multiplatform TProcess with STDIN/OUT interception, waiting for finish and so on. I wonder if something like that exists for Delphi (this should really be in RTL as it's "routine stuff")

Why were you using ShellExecute() for that? You should have been using CreateProcess() instead. To detect when the process ends, use WaitForSingleObject() or related function on the returned process handle. On Linux, you can start an external process using the fork(), exec...(), or posix_spawn() functions. To detect when the process ends, use wait() on the returned process ID.

Why are you using AnsiString at all? You should be using (Unicode)String instead, since that is what the TMemo expects. In any case, Char is WideChar in D2009+, so SizeOf(Char) is 2 not 1, so you are allocating memory for your AnsiString for only 1/2 of the file data, but then reading the full file into that memory. So you are going to corrupt surrounding memory. Use SizeOf(AnsiChar) instead, which is 1 so you can just drop the SizeOf() altogether. var LoadString: AnsiString; FS: TFileStream; begin FS := TFileStream.Create(FileName, fmOpenRead or fmShareDenyNone); try SetLength(LoadString, FS.Size); FS.ReadBuffer(Pointer(LoadString)^, FS.Size); finally FS.Free; end; Memo.Lines.Add(String(LoadString)); end; Alternatively, there are other options, such as TMemoryStream.LoadFromFile(): uses System.Classes; var LoadString: AnsiString; MS: TMemoryStream; begin MS := TMemoryStream.Create; try MS.LoadFromFile(FileName); SetString(LoadString, PAnsiChar(MS.Memory), MS.Size); finally MS.Free; end; Memo.Lines.Add(String(LoadString)); end; Or TStreamReader: uses System.Classes, System.SysUtils; var LoadString: String; Reader: TStreamReader; begin Reader := TStreamReader.Create(FileName, TEncoding.ANSI); try LoadString := Reader.ReadToEnd; finally Reader.Free; end; Memo.Lines.Add(LoadString); end; Or TFile.ReadAllText(): uses System.IOUtils, System.SysUtils; var LoadString: String; begin LoadString := TFile.ReadAllText(FileName, TEncoding.ANSI); Memo.Lines.Add(LoadString); end;

We use a couple of C# assemblies - mostly for being able to break down stuff like bar code scan strings into AIs, or other forms of string analysis, validation (checksums) or manipulation. It is a bit cumbersome, tbh, but it is a lot more efficient than trying to do the same stuff in T-SQL.

From what I saw regarding UDR's it's just a bloated nightmare even for elementary things. And they haven't got too much advantages over UDF's except sharing current connection/transaction handles.

Afaik ShellExecute returns nothing, it does not even confirm if the command line was executed or not. By sticking to it you have no other options but command line parameters, best case scenario is to encrypt the password and decrypt it from the second app. You can check the running processes after ShellExecute and grab it's handle for data transfer but this introduces a lot of unnecessary checks, like timeout (don't wait for the second process until you can find it, what if it did not even launch), did it already initialize and ready to accept data? If you use CreateProcess and map the stdin and stdout, you can make your first application to "type in" the user name and password to the second one and read back the output to verify if authentication was successful. However if both applications are written and managed by you, move the worker method to a .DLL and make the first and the second application to load and use it. You also have to validate the legitimacy of the library, though. Or to a helper unit, and do not even include a secondary file. However, external files will always pose a major security risk, especially if they need to share sensitive information. It's really easy to put a malicious .EXE file in place of yours (even if it's running) just to steal the credentials.

Consider using pipes, I believe they're a bit harder to sniff than command-line params. Of course you'll need full-featured CreateProcess for this. Or you may encrypt your data and send it via any channel. You can even implement full TLS handshake.

You probably need to decide what you want to be secure from. As it stands it's probably impossible to give you specific advice.

Totally agree with you.

"A Shell link is a data object that contains information used to access another object in the Shell's namespace": Read the whole definition here: https://docs.microsoft.com/en-us/windows/win32/shell/links I was searching for a Delphi VCL library allowing me to easily create a Shell-Link with all properties described in the Microsoft documentation: https://docs.microsoft.com/en-us/windows/win32/api/shobjidl_core/nn-shobjidl_core-ishelllinkw I found a lot of libraries for this purpose, but most of them were outdated or had some flaws or bugs. Most of the libraries lacked the feature to create a Shell-Link with a Hotkey. The ShellBrowser Delphi VCL Library from JamSoftware contains a method to easily create a Shell-Link: https://www.jam-software.com/shellbrowser_delphi/index.shtml Unfortunately, it has no easy method to configure the properties (especially the hotkey property) of the newly created Shell-Link. Fortunately, the above mentioned Microsoft documentation provides all the information to succeed in the task: I use a standard THotKey control in the UI to allow the user to configure a hotkey for the newly created Shell-Link: The THotKey control has these main properties - HotKey and Modifiers: So the whole process of creating the Shell-Link with the Hotkey properties can be achieved with these steps: 1. Get the ItemIdList of the created Link: 2. Provide the IShellLink Interface of the ItemIdList: 3. Declare the IPersistFile interface for the Shell-Link file: 4. Now we need (as mentioned in the Microsoft documentation) to store the virtual key code in the low-order byte and the modifier flags in the high-order byte of the Shell-Link Hotkey property. For this purpose we declare a record containing two byte-fields: Then we get the Hotkey from the THotKey control, assign it to the record and typecast the record to a Word: But the Modifiers value is still missing from the record. So next, we get the Modifier-keys from the THotKey control and assign them to the Modifier Byte of the record: Now we can assign the record (again typecasted to a Word) to the Shell-Link interface: 5. The other Shell-Link properties are easy to set and are explained in the Microsoft documentation. 6. In the last step we can now save the configured Shell-Link: You can download the source code and learn from its implementation: ShellLinkShortcutTest.zip Here is a compiled exe demo of the program: ShellLinkShortcutTest_CompiledExeDemo.zip To compile the source code yourself you need the ShellBrowser library. You can download a free trial version here: https://customers.jam-software.de/shellbrowser_delphi/download.shtml?language=EN The many other features of the ShellBrowser library are explained here: https://www.jam-software.com/shellbrowser_delphi/features.shtml I am not affiliated with JamSoftware, but I recommend the ShellBrowser library as an excellent product. I wish you a lot of fun with this demo!

https://web.archive.org/web/20171110112441/https://www.tek-tips.com/faqs.cfm?fid=7526

I just put it in my REAL application and it works great.

@John Kouraklis It works. I used this link http://arabteam2000-forum.com/applications/core/interface/file/attachment.php?id=159065 1. with Delphi 10.2.3 i used the berlin version 2. My test project is fmx+memo 3. I added THE 3 pas files 4. i added FMX.Canvas.GPU.pas from the Delphi fmx source 5. I added path of Delphi source fmx to my project 6. compiled 7. apk to my samsung s6 phone 8. DID NOT CHANGE NOTHING IN THE SOURCE !!!! 9. AND IT WORKS !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 10-. in my case it is HEBREW !! P.S 4 not needed as you have 5

@Serge_G Digging a bit from the link you added, here's an interesting project https://github.com/orwah/Arabic-Delphi-VCL-Units But it is for VCL only

Oh, it seem that was the TTextLayout.RighttoLeft who do the trick but did not work for Android 😣 and I do not know if it works for those Apple things My friend Nabil just send me an intyeresting link

Hi, I don't write nor read RTL languages, I wrote a function to detect if the text starts with a RTL char function checkRtl (S : string; Exceptions : String = '' ) : TTextAlign; var carray : array of WideChar; i : int64; ws : String; begin for I := 0 to 9 do S:=StringReplace(S,i.ToString,'',[rfReplaceAll]); // supprime autres caractères spéciaux S:=StringReplace(S,'(','',[rfReplaceAll]); S:=StringReplace(S,')','',[rfReplaceAll]); S:=StringReplace(S,'"','',[rfReplaceAll]); S:=StringReplace(S,'''','',[rfReplaceAll]); S:=StringReplace(S,'-','',[rfReplaceAll]); if not E.IsEmpty then begin for I := 1 to Length(Exceptions) do S:=StringReplace(S,Exceptions[i],'',[rfReplaceAll]); end; S:=Trim(S); // arabic + hebrew SetLength(carray,$6ff-$590); for I := $590 to $6ff do carray[i-$590]:=Char(I); // there are some farsi char to be added result:=TTextAlign.Trailing; if S.IsEmpty then exit; if inOpArray(S[1],carray) then result:=TTextAlign.Leading; end; And, with Nabil's Help I test my ideas in a grid. You can find (french) discussion here and my tutorial https://serge-girard.developpez.com/tutoriels/Delphi/Livebindings/Grilles/#LVII-C-1 I did not test for TEdit and TLabel though but my guess it is possible

I would suggest rewriting the function to something more like this: function IsFileInUse(const FileName: String): Boolean; var hf: THandle; begin hf := CreateFile(PChar(FileName), GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); if hf <> INVALID_HANDLE_VALUE then begin CloseHandle(hf); Result := False; end else begin Result := (GetLastError() = ERROR_SHARING_VIOLATION); end; end;

Yesterday I reinstalled Delphi in a fresh machine and upon registration I got the error of maximum registrations. I emailed EMBA and today they replied that increasing the limit for my license is part of technical support and as I am not under active subscription they are not very keen on helping me with this issue. They also mention that " Historically, we provided limited support for activities such as changing registration limits as a courtesy. Going forward registration limit changes will have to be approved by Renewals. We are working to provide a more automated way to facilitate this service in the future or eliminate the need for it altogether.I have copied the renewals team in this email response (renewals@idera.com). Your renewals representative will be able to assist you with options to renew your support and maintenance, as well as facilitate the necessary registration increases." I don't know guys what you think but for me this is outrageous. Actually it is a deal breaker. I am not asking to receive new updates---just to use the license I paid on a new machine.

There was a big discussion about this a while ago. After a lot of messing about it seems that registration bumps are now done by sales. The rather unclear message seemed to be that sales would try to sell you something but you would get your bump for free if you choose not to buy anything. Although, despite multiple people asking Atanas Popov for clarification, there wasn't anything clear forthcoming. Another major mis-step by Emba. Let us know how you get on with sales.

OK, several samples. FMX form with HtPanel on left and standard memo on right. Windows, standard FMX canvas: Here kerning pairs are correct on both sides and arabic letters are connected as it should and have correct order because FMX canvas use windows Direct2D layout for rendering. But word order in sentense with mixed english/arabic text is incorrect on right side and correct on left, because in HtPanel text is prepared by internal BiDi processor. Android, standard FMX canvas: On mobile platforms FMX output each letter as single bitmap. So kerning pairs are not processed and arabic letters are not connected. Word and letter order is correct on left side because of internal BiDi processor, but still no kerning and letter connectors. Android, native Android canvas: Kerning and letter connectors are correct. There is also another issue with FMX canvas ion mobiles. Here is the same form with scaling set to 10x for both components. FMX use bitmap scaling instead of preparing bitmaps for each font size. This leads to visual artefacts and blurred text.

FMX use different methods for text rendering on mobile and desktop platforms. On desktop platforms native OS methods are used (f.e. Direct2D text layout or CGContext) but on mobile platforms text is rendered as bitmap combination - each font symbol is stored in cache as bitmap. This leads to no RTL support, bad kerning, etc and also is slow., This is why I had to write native canvas support for these platforms.