Rollo62

It controls the mouse and you can transparently switch mouse and keyboard from one PC to the other, just by moving the mouse into the right viewport. That means you need 1x mouse and keyboard, but 2x display, one for each PC. That way you operate both machines at the same time, at least it feels like this.

This sorts it out for me

You could check https://symless.com/synergy Works like a charm for me, at fair costs

Maybe that can help? ( but you have to learn German first 🙂 ) https://www.delphipraxis.net/213780-bild-auf-timage-mit-svg-grafiken-zusammenfuehren-skia.html

https://github.com/DelphiWorlds/Kastri/tree/master/Demos/SpeechRecognition

That looks interesting, they seem to have fair conditions. What only puzzles me is, that they have not even a real snd proper impress & terms page, even if they were probably an EU company. At least I have not found Distribution and technical support for Winflector: OTC S.A. Krakow Poland OTC S.A. ul. Skotnicka 189, 30-394 Cracow, Poland Telephone: +48 12 626 36 36 WWW: www.otc.pl E-mail information: office@winflector.com Technical support: support@winflector.com Find us on Facebook: WinflectorCom Are they developer or distributor, who is the developer, who owns the software? That already gives a lot of pre-front negative impression and usually prevents me from even tests soutione like this.

Not sure if it meets your "app in a website" needs, but there is also TMS WebCore ... https://www.tmssoftware.com/site/tmswebcore.asp

Try this, untested uses System.Rtti, System.SysUtils, Vcl.StdCtrls; procedure TForm1.Button1Click(Sender: TObject); var RttiContext: TRttiContext; LType: TRttiType; ACaretPositionProp: TRttiProperty; Val: TValue; CaretPos: TPoint; begin RttiContext := TRttiContext.Create; try LType := RttiContext.GetType(TMemo.ClassType); ACaretPositionProp := LType.GetProperty('CaretPosition'); if Assigned(ACaretPositionProp) then begin Val := ACaretPositionProp.GetValue(Memo1); if Val.IsType<TPoint> then // Check if the value is of type TPoint (which is compatible with TCaretPosition) begin CaretPos := Val.AsType<TPoint>; ShowMessage(Format('Caret Position: X=%d, Y=%d', [CaretPos.X, CaretPos.Y])); end else ShowMessage('CaretPosition property is not of type TPoint.'); end else ShowMessage('CaretPosition property not found.'); finally RttiContext.Free; end; end;

I like to separate different aspects of stuff in completely different units, which where combined then in a wrapper unit, like so unit DecideWhichUnitInPlace; interface uses // This is the only place where separation takes place {$IFDEF UNIT_TESTING} UnitWithTests, {$ELSE } UnitWithoutTests {$ENDIF } ; //Even separate classes and interfaces like that, not only functions type // This can point to completely different, but cleanly separated versions, depending on defines {$IFDEF UNIT_TESTING} TMyType = UnitWithTests.TMyType; {$ELSE } TMyType = UnitWithoutTests.TMyType; {$ENDIF } ; implementation Then no defines are needed in those units at all unit UnitWithTest; interface uses Whateever, isNecesssary; function AlwaysAvailable(): TSomeType; function NotAlwaysAvaialble(): TSomeOtherType; type TMyType = class function AlwaysAvailable(): TSomeType; function NotAlwaysAvaialble(): TSomeOtherType; end implementation uses Other, Units; function AlwaysAvailable(): TSomeType; begin // implementation here end; function NotAlwaysAvaialble(): TSomeOtherType; begin // implementation here end; function TMyType.AlwaysAvailable(): TSomeType; begin // call AlwaysAvailable; end; function TMyType.NotAlwaysAvaialble(): TSomeOtherType; begin // call NotAlwaysAvaialble; end; end. This is not the beest example to explain this and it depends highly on what you really want to achieve. Maybe it gives you some helpful thoughts. unit UnitWithoutTest; interface uses Whateever; function AlwaysAvailable(): TSomeType; //function NotAlwaysAvaialble(): TSomeOtherType; type TMyType = class function AlwaysAvailable(): TSomeType; function NotAlwaysAvaialble(): TSomeOtherType; end implementation uses Other, Units; function AlwaysAvailable(): TSomeType; begin // implementation here end; //function NotAlwaysAvaialble(): TSomeOtherType; //begin // // NO implementation here, or completely removed //end; function TMyType.AlwaysAvailable(): TSomeType; begin // call AlwaysAvailable; end; function TMyType.NotAlwaysAvaialble(): TSomeOtherType; begin // call, ignore or mock, when function is NOT available //NotAlwaysAvaialble; end;

Hi there, I'm not asking how to make it default, this I did already. Every time when dealing with the "Standard Edit.Text" on "Standard Button's", I get to the point where I have and want to enable Edit.TextSettings.WordWrap. I'm wondering, what could be the original reasoning for the decision, to keep wordwrap initially inactive. Shall I keep WordWrap alway Active ? Pro's - Wrapping text in a button is in 95% of the cases a style "bug" and not wanted: The philosophy is "Prefer "info over style" - Under normal conditions, active wordwrap has no negative impact on the display - With normal, 1 line of text, no truncation occurs - Too long text can be more safely identified, more information can be seen - The wordwrap takes place automatically, by the detection of available space - In TButton's default settings, the button can usually display 2 lines of text reasonable well - Multiline text can show more info, even if parts of the text may be invisible - No ability to control what is main the focus of the text to be show - Best use of available display space, to maximize information - Too long texts can be easily spotted by the developer, makes it easier to fix Con's - Wrapping text in a button is in 95% of the cases a style "bug" and not wanted: The philosophy is "Prefer "style over info" - Text display is looking ugly when it wraps, it's formatted and styled - Perhaps slight performance issues, to detect line counts, and so on - The wrap situation cannot be controlled manually, if inactive it just never wrap's - Multiline text can lead to keep the start of the sentence out of the view, showing the middle of the whole text - No ability to control what is main the focus of the text to be show - Some implementation with ellipsis ( tuncated text... ) even reduce the available display space by additional ... characters - Truncated texts can be hardly spotted by the developer, not so easy to fix I wonder, if there is any good reason not to activate wordwrap in any case? Please let me know your opinion, and if you know cases, where the wordwrap is a no-go.

Yes, sorry, I should have made that clear. But my question is general. Same is for example VCL.TLabel, actually I'm not sure if wordwrap is active or not, but assume so. Perhaps these settings can be well explained by "history", in the old days it was a more massive mess, to produce multi-line thingies. Nowadays, with 8K screens its better. The "Intended to be one line" answer doesn't really explains a lot. Like said, also the Controls do nicely show Single-Line, while WordWrap on, so it doesn't really to foreced to 1-Line. The problem begins, if the controls receive unsuitable texts or dimensions, or suddenly foreign translation, then the issue gets visible. Why prefer not to handle such issues gracefully?

512GB HD If possible, choose a decent SSD, its worth it, even with a little cost-up.

As far as i know, Android x86 is not supported. You can check the current Plattform Status, i cannot check the dokwiki right now.

Right, but its the cheapest way to start M1+ development and even reasonable local AI expermiments ( Llama3 8B runs on M2+ not so bad, much cheaper than Nvidia GPU ). You can purchase an older, refurbished x86 machine maybe cheaper, but then you are stucked on x86, as fas as I can say will Apple hardly kill development any time they want.

Why not? If there is a change that he wants to create CrossPlattform Apps, this will be a good choice. With Parallels Desktop, it runs Windows, and as far as I know Delphi runs nicely on an M1 MacMini. I only use MacMini for XYCode purposes, so never tried to install Windows + Delphi there. It depends, depends, depends, on what you need.

So you would say Apple M3, M4 is not performant enough against Intel? You're maybe right in the top 5 positions, but there is also the parameter "Price". All in all, I would say ARM has the strong ability to overtake all parameters in the near future, while Intel struggels a bit at the moment.

My 5 ct: Either CISC Intel/AMD manage the complete U-turn to achieve CPU/GPU/NPU at lowest power consumption with highest performance at best economic cost, or RISC will win the race in the long run. Microsoft on ARM just shows that not everything has to be locked to x86, but also Android/iOS clearly show where the performance can be with ARM. For me, the question is not if, but only when the ‘ARM singularity’ will happen. If you believe in the CISC U-turn, then maybe it won't happen, but what magic wand would Intel/AMD have against Qualcom, Apple M1, Samsung, NVIDIA, TSMC and so on? You have to bury your head very, very deep in the sand to believe in x86's sole dominance.

https://docwiki.embarcadero.com/Libraries/Athens/en/System.SysUtils.DeleteFile

This is pretty much overwhelming. I'm afraid there is already a point here where users are shocked by the functionality and need a gentle way to climb the learning curve. In my opinion, it is always best to have many examples covering different levels of difficulty to understand the whole concept behind it piece-by-piece. If there is a clear usage concept behind it, how could you explain it in the docs, maybe step by step? Maybe a user needs a mix of Delphi and HTML/JS knowledge to understand most of it, how can these lessons be broken down into small, digestible chunks?

My update/upgrade process tends to be more and more complicated every year. This is much more enhanced right now: https://en.delphipraxis.net/topic/1336-fmx-crossplatform-best-practices-upgrading-1031-to-1032/?tab=comments#comment-11214 In short I would say, to be stable in FMX cross-platform: - Use VM, backup VM - Clean VM, remove any part of IDE (means also cleanup certain folders after uninstall, to remove any missing items), Interbase, SDK's, JavaJRE, ... - Clean install IDE - Check & set paths - Check & set environment variables - Setup IDE, but mainly keep original settings as-is - Install used components & experts - Add SDKs in SdkManager & Update local cache - Create empty projects, with default settings, to check for any changes in .dproj, Android.template.xml, iOS.plist, etc. - Duplicate any projects .dproj into new version folder (! so not overwriting the former version) - Open .dproj w/ IDE and compare for changes and compare with new, empty project, for added or changed items - Open UnitTest, check for failures - Open main libraries, install & test - Open project 1, Android update libraries, test ....

What about // Key Value TDictionary<Integer,string> with Integer Key as Hash from the original string? This will allow you to handle and operate with key's and only retrieve the real, original strings whenever necessary.

Hi there, I had again alonger session, making me headaches with mobile development. Android 12-14+ should currently be affected, I was able to prove this on various devices. The problem: With normal IoT applications, there is the option of using the ‘neverForLocation’ flag to bypass the annoying location query. So far, so good, this works with the normal BLE modules. However, there are products that appear as IoT with a normal, general serial interface ( Characteristiocs Write / Read / Notify ), but in which obviously a beacon chip is installed internally, which outputs a beacon / iBeacon identifier. The special beacon function is not used at all, but is only present in the ‘Manufacturer specific data’ of the chip. The device can be addressed normally via the characteristics and it works as it should. However, if the ‘neverForLocation’ flag is used in the manifest, these IoT devices are suddenly no longer listed in DeviceDiscovery. This makes sense, of course, because a beacon is a location-based device. It is noted here under the Bluetooth definitions: The solution: Doesn't seem to exist. # Either remove the ‘neverForLocation’ flag, then it works, or # Do not use a BLE module that is pre-programmed for Beacon/iBeacon. You can identify the modules with e.g. the nRF Connect app in the list as ‘Device XYZ (iBeacon)’, you can click on them and display further data with ‘more’: ‘Company: Apple, Inc. 0x04’ and ‘Type: Beacon: 0x02’. The LightBlue app shows ‘Device XYZ’ in the list, if this is clicked, then further data is shown. Among other things, the ‘Manufacturer specific data: ’Apple, Inc. (0x4c): 0x0215FDA5....’ This identifier 0x4C02 therefore seems to be decisive for the categorisation as an iBeacon. Are there maybe any other possible solutions, to use iBeacon, but still get listed in a normal DeviceDiscovery? If not, then at least I hope my description might others stepping into the same trap.

Not followed here exactly, but I would always recommend to try to check exactly the same path: if TFile.Exists(JStringToString(PackageName)) then begin TFile.Delete(TPath.GetHomePath + PathDelim + 'myDatabase.s3db'); maybe like this, if both "exists" are relevant if TFile.Exists(JStringToString(PackageName)) then begin if TFile.Exists(TPath.GetHomePath + PathDelim + 'myDatabase.s3db') then begin TFile.Delete(TPath.GetHomePath + PathDelim + 'myDatabase.s3db'); end; ...

Now I stop having too many bad thoughts about the whole Tiobe-System, thank you, its all right again and I start liking it

Perhaps using threads might help, to keep animations flowing. But to be honest, I really would rather skip the whole SplashScreen idea at all, especially with animations. Even using threads might get into nightmares, not worth the efford at all, for example splash screens might stay invisible, behind other processes etc. From my experience, splash screens are a call for problems only. It might confuse, en-nerve your users, waiting for something usable showing up. My preferred strategy, if that is possible ( not always can be done like this ), show the main entry page as soon as possible in a greyed out manner maybe plus "loading ..." label, and lazy-load the rest of the app afterwards. This gives a much better, responsible user experience IMHO, which is not interruppted or cluttered by splash-screens, which always felt to be too long.