![Delphi-PRAXiS [en]](https://en.delphipraxis.net/uploads/monthly_2018_12/logo.png.be76d93fcd709295cb24de51900e5888.png){kind=logo}
All Activity
This stream auto-updates
- Today
-
I just installed the latest version from github, it does exactly the same.
-
Probably nothing :). The default setting for range checking changed to "on" and the Lockbox version in GetIt may not reflect that yet. Try to use the latest version from github instead: https://github.com/TurboPack/LockBox3
-
I couldn't reproduce, but I am on 12.3 here. Can you give detailed steps to reproduce? Perhaps I tested something plain simple while the real problem is more complex.
-
Delphi 12.2, I installed LockBox 3 via GetIt. So far so good. I try to generate public and private keys, but I get all the time a range check error. Here is the example code: CryptoLib := TCryptographicLibrary.Create(nil); CodecRSA := TCodec.Create(nil); Signatory := TSignatory.Create(nil); CodecRSA.CryptoLibrary := CryptoLib; CodecRSA.StreamCipherId := 'native.RSA'; CodecRSA.AsymetricKeySizeInBits := 1024; Signatory.Codec := CodecRSA; Signatory.GenerateKeys; // <== Range Check Error Signatory.Free; CodecRSA.Free; CryptoLib.Free; What am I doing wrong?
-
The World of WEB – Free Webinar
TMS Software Sales posted a topic in Tips / Blogs / Tutorials / Videos
Are you a Delphi developer curious about building apps that run directly in the browser—without installs, without plugins? Want to learn how to create modern, responsive UIs using ready-made HTML & CSS templates, all from your Delphi IDE? Then don't miss our upcoming The World of WEB webinar! This session is perfect for beginners or anyone new to TMS WEB Core. We'll guide you step-by-step to help you get started quickly and confidently. 📅 Wednesday, June 18, 2025 ⏰ 3:00 PM UTC | 5:00 PM CEST ✅ Free registration ✅ Live demo ✅ Q&A with the experts 👉 Sign up now: https://www.tmssoftware.com/site/tmswebacademy.asp?id=169 We can’t wait to see you there! 🙌 -
HI, I am using Modelmaker and Delphi 12.2 The Modelmaker integration expert has been working well, but just recently I can't use the locate in Delphi button, it is just greyed out. The Modelmaker integration option in Delphi work though. Any ideas? Is there something obvious I have missed?
-
Added RSA_Verify prototype in OverbyteIcsLIBEAY
Angus Robertson replied to Frédéric's topic in ICS - Internet Component Suite
On reflection, I will add your new prototypes to ICS. I was going to suggest you created your own import table with the RSA functions, similarly to the OpenSSL engine table that requires a define conditional to import. But ICS has a problem with the OpenSSL import tables getting larger as new functions are added, but old ones rarely disappear when they cease being used. So I'll create a new import table that will have most of the RSA_, ECDA_, DH_., EC_KEY_, EC_GROUP_ and DSA_ exports, with a new define around all those functions and the table, to ensure that none are currently being used by ICS. I already had to remove some EC_GROUP_ exports that have disappeared from some Linux distributions. Should be in SVN in a couple of days. Angus -
I have found no official way, but created this, which seems to work (after calling JPEGNeeded): type tJpegImageClassHelper = class helper for tJpegImage public procedure SetResolution(aDpiX, aDpiY: word); end; tJpegDataClassHelper = class helper for tJpegData public procedure SetResolution(aDpiX, aDpiY: word); end; procedure tJpegImageClassHelper.SetResolution(aDpiX, aDpiY: word); begin with self do if fImage<>nil then fImage.SetResolution(aDpiX, aDpiY); end; procedure tJpegDataClassHelper.SetResolution(aDpiX, aDpiY: word); type tJpegApp0Rec = packed record // 18 B including the marker; starts on position 2 in the file APP0Marker: word; // 2, FF E0 Length: word; // 2, Length of segment excluding APP0 marker Identifier: array[1..5] of AnsiChar; // 5, 4A 46 49 46 00 = 'JFIF' in ASCII, terminated by a null byte JFIFVersion: word; // 2, First byte for major version, second byte for minor version (01 02 for 1.02) DensityUnits: byte; // 1, Units for the following pixel density fields; 00 : No units, 01 : Pixels per inch (2.54 cm), 02 : Pixels per centimeter XDensity: word; // 2, Horizontal pixel density. Must not be zero YDensity: word; // 2, Vertical pixel density. Must not be zero XThumbnail: byte; // 1, Horizontal pixel count of the following embedded RGB thumbnail. May be zero YThumbnail: byte; // 1, Vertical pixel count of the following embedded RGB thumbnail. May be zero // ThumbnailData... // 3 × n, Uncompressed 24 bit RGB (8 bits per color channel) raster thumbnail data in the order R0, G0, B0, ... Rn-1, Gn-1, Bn-1; with n = Xthumbnail × Ythumbnail end; pJpegApp0Rec = ^tJpegApp0Rec; var App0: pJpegApp0Rec; function Swap(Value: word): word; begin result := (Value shr 8) or ((Value and $FF) shl 8); end; begin with self do begin if fData = nil then exit; if fData.Size < 20 then exit; App0:=pointer(NativeUInt(fData.Memory) + 2); if App0^.Identifier = 'JFIF'#0 then begin App0^.DensityUnits := 1; App0^.XDensity := Swap(aDpiX); App0^.YDensity := Swap(aDpiY); end; end; end;
-
Hello, I would like to set the resolution of tJPEGImage, such as 300 dpi. Is it possible, or the only way is to save jpg and then directly overwrite corresponding bytes in the file/stream?
-
Feature Request for the Delphi Language (Rethink or Eliminate the Concept of Units)
Uwe Raabe replied to dmitrybv's topic in Algorithms, Data Structures and Class Design
Well, in this case you can. I did a lot of refactoring such code myself during the last decades. The constraint you suggested to remove is a good indicator of progress in such an endeavor. -
Feature Request for the Delphi Language (Rethink or Eliminate the Concept of Units)
DelphiUdIT replied to dmitrybv's topic in Algorithms, Data Structures and Class Design
@dmitrybv The concept you express, that of simplifying the organization of the code in some way, has been discussed several times (so much so that now we can build the view of the "link" tree). However, the current organization, in my humble opinion, allows us to maintain a well-separated and at the same time compact organization of the code. The concept of "breaking" the code into unitary elements fits perfectly with the concept of units. It also fits with the concepts of scope (private / strict private / ...) and how they are now applied. The problem of "blocking" circular references is actually a problem that concerns the implementation of the code not carried out with rigor. Out of haste or inexperience, everything is put into a few units and then ... "you can't unring the bell". The concept of packages is already present (see third-party distributions or even bundles like Indy or FireDAC) but the use is still tied to units, and so you can "load" only what is necessary without having to compile the entire package, ensuring a fast and compact generation (... compact ... 🙂maybe it could be improved) of the executable code. For the runtime the concept of packages is already present similarly to other "languages". Of course, it is necessary to know what to reference as a unit but it is a hurdle that is easily overcome with time ... and it also helps to understand how the package was conceived and organized (which never hurts). -
TMS Smart Setup is now open source
Patrick PREMARTIN replied to A.M. Hoornweg's topic in Delphi Third-Party
Great move for an interesting product. It remains to be seen how the “market” will evolve in relation to other package and dependency management systems available for Delphi or Pascal projects in general. -
Added RSA_Verify prototype in OverbyteIcsLIBEAY
Frédéric replied to Frédéric's topic in ICS - Internet Component Suite
Thanks for the tip, I will give it a try !! Frédéric -
Feature Request for the Delphi Language (Rethink or Eliminate the Concept of Units)
Dalija Prasnikar replied to dmitrybv's topic in Algorithms, Data Structures and Class Design
This has only been an issue if you make a mess out of your code design. In rare situations where you do need circular references using implementation section in one unit will suffice. I doubt that proposed changes would bring too much overall benefit and they would require extensive rework of the existing compiler architecture. There is existing feature which would be more beneficial for code organization: class helpers. Currently there is only a single supported helper in scope and having multiple ones would allow breaking down more complex code and organizing it into separate files. Implementing those would be a much simpler task, consistent with the existing architecture. -
tenaroj joined the community
-
Smart Setup is a unified tool for installing and building Delphi packages, whether they come from TMS or elsewhere. See: https://www.tmssoftware.com/site/blog.asp?post=1360
-
Description: In Delphi, it's not possible to list units that reference each other in the interface uses section. This limitation significantly hinders class organization within a package. Initially, developers work around this by moving some unit references to the implementation uses section. However, as the class hierarchy becomes more complex, this strategy breaks down. At a certain point, class inheritance and cross-referencing between units can no longer evolve naturally due to circular reference restrictions. Instead of focusing on building a clean and scalable architecture, developers are forced to spend an excessive amount of time carefully juggling interface and implementation references across units to avoid dependency issues. Suggestion: Consider removing the concept of unit as a fundamental structural element in Delphi’s object model, and instead rely entirely on package-based architecture. Classes within the same package should be able to access each other regardless of which unit they reside in, without exposing their internal structure outside the package. If this change is too radical for Delphi’s current model, a more incremental alternative could be introduced: Allow splitting of interface/implementation code across multiple files, which could then be merged by the compiler or a preprocessor into a single internal unit. This would simulate package-level cohesion without breaking existing language design principles. - Yesterday
-
Thanks for reporting. I think the correct URL to the QP issue should be this one. That being said, I tested compiling the test project on Delphi 12.2, running on a Samsung A15, and on dragging the green caret the app doesn't crash, but it is really glitchy: - It freezes a couple seconds before the magnifier spawns, only to hang another couple seconds until it goes away (still running after that, and Monitor reports things like "Skipped 169 frames! The application may be doing too much work on its main thread."). - After some minutes running the app starts to paint itself incorrectly (see attachment). - After sending the app to the background and restoring it its all black, but I can still interact with the TEdit apparently. At this point Monitor shows tons of "ERROR: Format allocation info not found for format: 38" and similar messages. Looks like a combination of features that went untested and is very unstable. I would stay away from this combo until fixed. video5066602786846672458.mp4
-
It might help to show the rest of your code
-
Quick-Report - Pointer Error - Composite Report
Hans J. Ellingsgaard replied to ebachs10's topic in Delphi Third-Party
My guess is that you are free'ing the ComponentForm while it is still beeing used. -
Quick-Report - Pointer Error - Composite Report
Brian Evans replied to ebachs10's topic in Delphi Third-Party
That looks like the wrong thing to be working on - an unrolled loop vs a loop just isn't a big deal. Likely separate units so each could be customized but that didn't end up being required. Or some actually are customized by having different properties set for the same base QuickReport layout or in some other way. -
Any delphi components for VNC or RemoteDesktop?
aehimself replied to ChrisChuah's topic in General Help
When experimenting with a new component I suggest a "barebone" example first. One control on the form, setting up and connecting in FormCreate. I'm not going to recreate your form layout and filter out the essentials I'm sorry... I already showed how I'm doing it and it works fine. Also keep in mind that by importing the MsTscAx control you are effectively using the current version available in your Windows setup: it can / might / surely will differ between versions, editions and even patch levels. -
Hi All, I’m relatively new to Delphi and have recently taken over maintenance of a fairly large application that uses QuickReport extensively. The project’s architecture leaves some room for improvement, but given its size, I plan to refactor it step by step. Problem Description: I need to create a composite QuickReport that includes several reports of the same type, all based on a shared report template. Currently, the application structure includes: A main unit, let’s call it Components_CompositeReport, which orchestrates the reports. For each of the 40 components, there’s a dedicated unit (e.g. ComponentReport1, ComponentReport2, … ComponentReport40), each containing the same QuickReport layout. Unfortunately, this setup means that any layout change has to be replicated across all 40 units, which is inefficient and error-prone. Current Structure: In each unit (e.g. ComponentReportX.pas), the only logic is: var aComponentReportFormX: TComponentRptFormX; function ComponentReportFormX: TComponentRptFormX; begin if not Assigned(aComponentReportFormX) then aComponentReportFormX := TComponentRptFormX.Create(nil); Result := aComponentReportFormX; end; For report unit 1 (ComponentReport1), there’s some additional logic to map global data. In the composite report unit (Components_CompositeReport), the current approach looks like this: if Component1Exists = True then begin ComponentReport(1,1); Add(ComponentReport1); // Add to composite report end; if Component2Exists = True then begin ComponentReport(2,2); Add(ComponentReport2); // Add to composite report end; // … and so on for each component What I Want: I’d like to consolidate the design into a single unit containing the QuickReport layout, and instantiate it dynamically for each active component. I tried the following approach: for i := 1 to 40 do begin ComponentForm := TComponentRptForm.Create(nil); ComponentReport(i, i, ComponentForm); Add(ComponentForm.Report1); ComponentForm.Free; end; However, this results in a pointer error: --------------------------- Program --------------------------- Access violation at address 009CA9ED in module 'Program.exe'. Read of address 0000030D. --------------------------- OK --------------------------- Question: How can I correctly implement a single QuickReport layout that’s reused dynamically for multiple components? What’s causing the access violation error in the code snippet above? Is there a recommended way to structure a dynamic composite QuickReport in Delphi to avoid duplicating the layout across multiple units? Any guidance or best practices on how to proceed would be greatly appreciated! Thanks in advance for your help. /Esben
-
I need to share a file using Android built-in handlers - e.g. email/whatsapp etc. This is done by creating a TJintent and giving it a URI containing the filename I can get the share activity up, however any attempt to give it the filename results in a security exception 'FileURIExposedException' Apparently you used to be able to just give it a 'file://' URI, but later version of android blocked this. Does anyone have a sample program that does this ? It may need modifying the manifest file ?? I have allready added Intent.addFlags(TJIntent.JavaClass.FLAG_GRANT_READ_URI_PERMISSION); to the intent but that does not help. The file is in TPath.GetSharedDocumentsPath Thanks.
-
No, you understand it right, just not Epsilon, that is annoying. Not sure about naming it Tolerance or tor though.. because somehow feels misleading too like epsilon, The use of Delta mostly comes form the word Distance and used as such. also Delta in general associated with difference between two values, and it is de facto the standard distance between points or values ( like |x-x0| = Dx , or |x,y| =Dxy ....), vectors (in geometry) etc May be Threshold, ComparisonThreshold, AcceptedDistance , MaxDifference, AllowedError, AllowedDistance ...
-
Jandjals joined the community
-
The principle of a function that compares real values for equality, up to a specified tolerance, is a valid thing to do in many cases. But there are lots of caveats. In practise, most developers (and far from just in the Delphi space) that I see recommending it are completely unaware of these caveats. Some of these caveats and issues: How do you choose a tolerance? Does your tolerance account for the scale of the values, and indeed should it? Some use cases demand absolute tolerances, some demand relative tolerances. If you are accounting for scale, how do you choose the scale? Is it based on the pair of values being compared, or should it be based from the total pool of values. For instance, you might have two series that you wish to compare. Shouldn't the scale be based on the series rather than individual samples? Or maybe it is individual samples. It's easy to mistake this as an equality, but the resulting relationship implied by equality to tolerance is not transitive, so is not a mathematical equality. That is a R b and b R c does not imply a R c. Looking more specifically at Delphi's SameValue, the tolerance used when the Epsilon parameter is zero (or omitted) is very odd. I definitely think puppies are dying left, right and centre when that code path is chosen. One of the common misconceptions with floating point is that it is not exact. I think of it as exact, subject to the rules of the domain, but the key point is that not all values are representable. So if you have floating point values a and b, then they represent some precise real value. But when you do a * b, say, then the true value may not be representable. And so the result is the closest representable value. This is well defined, and reproducible. A lot of people think that there's just some random errors and fuzz in it all. That FuzzFactor constant in the RTL source seems to be a classic example of that sort of thinking. This famous question on SO is a useful resource: https://stackoverflow.com/questions/588004/is-floating-point-math-broken One of my pet bug bears in Delphi is its inability to convert correctly between floating point and textual representations. In every other mainstream language (and most non-mainstream languages) this is possible. But in Delphi the code used to perform these conversions is home grown and broken. There are good algorithms for doing this, and it's a subject of active research, but Embarcadero don't seem to care about this. In my codebase I use correct algorithms. Which means that for all values I can convert from float to text and back and always get the same value. The inability to do this often leads to users calling SameValue. My own codebase does call comparison function that compare for equality to tolerance. But there is a lot of care taken in how the tolerance is chosen and applied. I guess that's the crux of what I am saying. So many people just say, this is hard, slap a tolerance onto the comparison that is good enough for the two values I have to hand, and surely that's fine for all other values! I'm a bit of a pedant in this area, I admit. But it's kind of my job to be. Sorry!
