Rollo62

By .DMG ??? ..... NOOOOT

Right, I also try to do keep the balance right. Usually I see modular units that define one functionality as "implementation details" of an interface, which may or maybe not involve one or more Units to do its implementation. When accessing this "functionality" through the interface, yes there may be a few units involved behind the scene, but not from the caller perspective ( he only needs one clean, simplified interface unit ). Higher complexity may arise from the implementation side, but thats worth it in my opinion, to keep such details separate whereever it make sense. For me it is most important to have a clean consumer side, which can be used many times in many places, while the implementation side is defined and tested only once mostly. You may call it imbalance, but I think the consumer side has higher weight than producer side.

Like said, same app, since I heavily modularized I have not seen such issues any more. I don't recall, but in the past iOS or Android had some kind of 64K limit for relative jumps, I think. It was always my explanation that too large binary blocks might fail, while the linker could handle many smaller chunks as needed ( probably that view is too naive with modern linkers, but anyway this helped a lot). These were cases from the early beginning of FMX mobile, so maybe all that has changed a lot, over the last years anyway. Nevertheless, my principle to try to use only small units had a lot of other advantages too and I'm quite happy with it.

All above said is right. I also want to mention that it may depend from Platform as well. While large units under Windws never made a big issue to me, it turned out that under mobile they may show various strange exceptions and crashes, under iOS or Android. I assume that the reason for this is because linker issues, since a simple re-order units might help in many cases. That is the main reason I try to highly decouple my units nowadays, even if the classes might be related. This is not only a better, modular design IMHO, easier to maintain and test, but also helps to prevent mysterious exception under Mobile

Maybe with a little "DIY", with Yocto-Serial module, this could be useful: https://www.yoctopuce.com/EN/article/interfacing-a-wiegand-rfid-reader-by-usb https://www.yoctopuce.com/EN/products/usb-electrical-interfaces/yocto-serial It has Delphi support too https://www.yoctopuce.com/EN/libraries.php https://github.com/yoctopuce/yoctolib_delphi

...

Right, could be also written like that: //if AList[ i ].IndexOfAny( CDigitChars ) < 0 then if AList[ i ].LastIndexOfAny( CDigitChars ) < 0 then begin AList.Delete( i ); end;

It would be also an option to use IndexOfAny, like this: unit UMain_Frm; interface uses System.SysUtils, System.Types, System.UITypes, System.Classes, System.Variants, FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs, FMX.Controls.Presentation, FMX.StdCtrls, FMX.Memo.Types, FMX.Layouts, FMX.ScrollBox, FMX.Memo; type TForm1 = class(TForm) Button1: TButton; Memo1: TMemo; Layout1: TLayout; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form1: TForm1; implementation {$R *.fmx} const CDigitChars : array [ 0..9 ] of Char = ('0','1','2','3','4','5','6','7','8','9' ); procedure doWithList( AList : TStrings ); var i: Integer; begin AList.BeginUpdate; try for i := AList.Count - 1 downto 0 do begin if AList[ i ].IndexOfAny( CDigitChars ) < 0 then begin AList.Delete( i ); end; end; finally AList.EndUpdate; end; end; procedure TForm1.Button1Click(Sender: TObject); begin var LList := TStringList.Create; try LList.Assign( Memo1.Lines ); // LList.Add( 'abc' ); // LList.Add( 'def23' ); // LList.Add( 'fgr65' ); // LList.Add( 'kbt' ); // LList.Add( 'idopt87' ); doWithList( LList ); Memo1.Lines.Assign( LList ); finally FreeAndNil( LList ); end; end; end.

Its not a listbox, but maybe the System.IOUtils unit help you with that.

I have tested Mitovs libraries too and they offer great stuff for video processing. But a complete traffic counter would be not easy to do, last time I checked the libraries only included some standard filters, like Hough, Canny, simple MotionDetection, etc. This can be maybe helpful to build a simple traffic counter, but I would assume that this performance will be not too good. Thats why something like Yolo has been invented, also because this is much faster and stable. I have tried some simple object detection algorithms of more or less static images some years ago and I can tell you that the normal image filters cannot magically give good results. It is very tricky to make them return stable and error-free results, especially if the scene is highly dynamic like traffic and if it can have different lighting situations. If you have some good ideas or solutions, would be great to see that too.

Video processing is once thing, but maybe you are looking for object detection algorithms like Yolo too. https://www.delphipraxis.net/1428590-post11.html I'm not sure if VideoLab implements that or would let you support that, that would be good to know. One thing to consider is maybe Python with OpenCV too, the Python environment could make such task simple, but I'm unsure if that has enough performance for realtime analysis https://medium.com/@MrBam44/yolo-object-detection-using-opencv-with-python-b6386c3d6fc1 https://towardsdatascience.com/yolo-object-detection-with-opencv-and-python-21e50ac599e9 https://opencv-tutorial.readthedocs.io/en/latest/yolo/yolo.html https://pyimagesearch.com/2018/11/12/yolo-object-detection-with-opencv/

Maybe you also have a look into UIResponder, which sits in unit iOSapi.UIKit. https://developer.apple.com/documentation/uikit/uiresponder/1621090-motionended https://pinkstone.co.uk/how-to-implement-a-shake-gesture-in-ios/ https://www.informit.com/articles/article.aspx?p=2026017&seqNum=12 https://ios-developer.net/iphone-ipad-programmer/development/accelerometer/shake-detection https://stevenpcurtis.medium.com/detect-ios-shake-gestures-swift-5164a5695d47

Not installed 11.2 yet, so just a rough guess ... Have you added the Sqlite libraries under Project/Deployment, "Add Featured Files", there you can click to add the Sqlite Engine.

I have learned the hard way that its a bad idea to use XCode beta versions, since they might not match to the iOS versions well and also might show many installation quirks. Thats why I usually wait until at least the finals were ready (also they contain glitches from time to time).

@Michalis Kamburelis Good to hear that your great project is now Delphi compatible. I have read before that it was only partly Delphi compatible, nur sure what that meant. Would you say this is now "fully" supported, or are there still some stumbling blocks and construction sites to watch out for ?

I have not tried yet either, but It should be OK if you currently can work on actual XCode13 and OS15.x. Apple usually gives some grace time before it forces you to change to XCode14 or newer iOS Version. This is usually compatible, of course the new features were not in. Since there had been also display dimension changes, it could be possible to see some quirks then on iOS16, but I dont really think that will happen. That was the case last time when Apple introduced the notch, in an earlier version.

Yes I do, I'm already standing there with all the animals around, waiting for the flood to rise.

Yes, thats problably true ..... until the day when its NOT Why gambling russian roulette, just to save a few minutes time ? Anyway, everybody has to make his own decision about this, probably in some cases ra build needs not minutes but days, then I could understand this decision. Usually I'm starting first tests also with maybe only 80-90% of libraries rebuild, but then the goal is to re-build the rest ASAP in the next days.

In the webinar Q&A Marco Cantu was confirming that this update is binary compatible to the last version and that this was deeply tested before release. But to be honest, I would never trust such information, no matter how deeply this was tested, only because of saving a few extra clicks and re-builds of BPL's and DCU's. I usually re-build everything after every update and had no "hard-to-find", "mystical" problems and crashes ever since, at least under Windows platform.

TTimer I would use only for moderate, small times, lime 100ms, 1sec, 30sec. for sure much less than a day. If you really need to monitor several days you better look after TStopwatch or even a simple TDateTime, which can easily check the elapsed time against an initially stored start-time. When the start-time is implemented as persistent data and can can withstant app-re-start and OS re-boot, you are on a much safer side. You might know: Time is the only really reliable, unique running counter ....

Would the System.IOUtils TDirectory.Delete() work for you ? It has the "Recursive" parameter option. class procedure TDirectory.Delete(const Path: string; const Recursive: Boolean); var PostCallback: TDirectoryWalkProc; begin CheckDeleteParameters(Path, Recursive); if Recursive then begin PostCallback := function (const Path: string; const FileInfo: TSearchRec): Boolean var CompletePath: string; begin Result := True; if (FileInfo.Name <> TPath.FCParentDir) and (FileInfo.Name <> TPath.FCCurrentDir) then begin CompletePath := TPath.DoCombine(Path, FileInfo.Name, False); // clear read-only, system and hidden attributes that can compromise // the deletion {$IFDEF MSWINDOWS} FileSetAttr(CompletePath, System.SysUtils.faNormal); {$ENDIF MSWINDOWS} case FileInfo.Attr and System.SysUtils.faDirectory of System.SysUtils.faDirectory: // remove empty directories RemoveDir(CompletePath); 0: // remove files DeleteFile(CompletePath); end; end; end; // delete all the files and subdirectories WalkThroughDirectory(Path, '*', nil, PostCallback, Recursive); // DO NOT LOCALIZE end; // delete the directory itself {$IFDEF MSWINDOWS} FileSetAttr(Path, System.SysUtils.faNormal); {$ENDIF} RemoveDir(Path); end; BTW: It has also a CreateDirectory, which uses ForceDirectories(FullPath); and seems a little bit more reliable class procedure TDirectory.CreateDirectory(const Path: string); var FullPath: string; begin FullPath := TPath.DoGetFullPath(Path); CheckCreateDirectoryParameters(FullPath); ForceDirectories(FullPath); end;

Alternatively you could use a VM, like VmWare. Just duplicate the whole current active image as backup, instead of fiddeling around with backup software within a VM. Migrate to a bew version: Duplicate the current active image into a new image Cleanup the copied, new image without hesitating too much, just brutally throw out all unnecessary stuff and clean everything (you could even start from a brand-new, clean VM, but this is rarely necessary). Resize and shrink the cleaned VM afterwards. Install the new version in the new image and test it. In case everything works fine for you, you don't even need to copy anything around. Just keep the new image and mark it as current image from now, while you can mark and use the last current image as backup.

My guess from your rough description is that you want to store data locally which might sum up day by day to a huge number. In that case I think a real capable local DB, like Sqlite, should be preferred over an in-memory TFdMemTable.

Here is some more background. Unfortunately I don't know a complete list of Android devices with 64-Bit CPU running under 32-Bit OS, maybe somebody has found such complete list somewhere ? I know that the Google Playstore has a huge devices list, but never looked deeper into this, howto export such information.

Simulator is currently not supported https://docwiki.embarcadero.com/PlatformStatus/en/Main_Page