Leaderboard

Magenta Hardware Components is a set of six main components for Delphi 2007 to Delphi 11.0 and later, as follows: 1 - Magenta Serial Port Detection Component which contains serial COM port enumeration functions, using several methods which can identify different ports depending on how they are installed, all are combined and a sorted array returned with friendly names and install information. 2 - Magenta Hardware Events Component that listens for Windows hardware event messages and calls events handlers for device changes such as serial ports, disk volume changes, low disk space events and power events. 3 - Directory Changes Monitoring Component, that notifies changes in a directory such as file or directory Create/Delete/Modify/Rename. 4 - Magenta GPS and Location Component is designed to process GPS location data from various sources with an event triggered when movement is detected. GPS sources supported include Windows Location API, NMEA 0183 sentences, GT02 GPS Tracker Protocol, TK102/103 Tracker Protocol and WondeX/TK5000 Tracker Protocol. Sample shows movement track on a Google map. 5 - Magenta Firewall Component has functions to search and list selected Windows Defender Firewall rules and settings, and to add and remove such rules. There is also some code that may be used in Inno Setup scripts to set-up firewall rules during application installation. 6 - Magenta Check Disk and Format Disk component used to format fixed or removable disk drives and perform disk checks on Windows NT4 and later. More details and download from: https://www.magsys.co.uk/delphi/maghardware.asp Or SVN: https://svn.magsys.co.uk/svn/maghardware/ Magenta Hardware Components are freeware, but are still copyrighted by Magenta Systems Ltd who may change the status or withdraw it at any time, without notice. Angus

The early 2000s want their website design back

I saw this post in German Delphi-Praxis: https://www.delphipraxis.net/209869-firedac-moeglichkeit-die-abfrage-schneller-zu-machen-delphi.html So, anybody, who have account on both forums can answer there ... "Normally" constants vs parameters slowness is due to bad query execution plan when the parameters are in use. For example, Oracle (and not only) will stop to use indexes, when a parameter data type is not the same as a field one in a WHERE clause. This is because a type conversion is required, even if it looks "obvious". For example, a field is VARCHAR2 and a parameter is defined as ftWideString (eg, assigning it using Value / AsWideString instead of AsAnsiString). There are more examples ... From Oracle doc (https://docs.oracle.com/cd/B19306_01/server.102/b14211/ex_plan.htm#i3305): PS: As always, a Delphi version will be good to know ...

The new GExperts version still supports all Delphi versions back to Delphi 6 (with the notable exception of Delphi 😎 and even the Delphi 11 version is no longer in Alpha state (but it’s still beta, there will be glitches!). Support for per monitor DPI awareness should now work (in Delphi 11, and definitely better than in the IDE itself). There are even a few new features ... Read on in the blog post.

Uwe, I've been meaning to thank you for this. Not for anything related to the Interface, per se, but it solves a problem I've encountered many times in the past dealing with the fact that these TListItem.Data members are Pointers rather than Objects, and they get gnarly to deal with because you constantly have to cast them. Sometimes I cast them improperly and sometimes they get deleted or orphaned unintentionally. Here just pretend that ISnapTally is really TSnapTally, and that's really just some type <T> that I happen to be working with. In this case, I thought creating an interface would make managing the Data members easier, but it didn't. What I ended up doing was creating a TListItemHelper class that has three different "overlays" for the Data member depending on context. (Different ListViews save different objects in their Data members. Since you can only have one helper per class, I just put support for all three types into the helper, since the TListItem is unrelated to the ListView that's holding the data. I mean, I could derive different ListViews but the TListItem is the same for all of them; it isn't easily subclassed to override the type of the Data element depending on the ListView. So while this is not a very elegant solution, it's simple and it works nicely.) However, what I did to solve the persistency issues was I created a separate TList<TSnapTally> and called it SnapTallyBag. Then modified the Set and Get to work indirectly by saving the index into the list as the value of the Data item, rather than a pointer to the item itself. I simply add stuff to the bag, doing a test for existing instances so there are no duplicates. And I never delete anything until I get to a point where I need to clear the ListView, then I just flush the contents of the bag. When the form closes, if it's not empty, then I flush it at that point as well. It just never occurred to me to use a class helper this way. So that's what I got from this, and it was far more helpful than the Interface hack. 🙂 In fact, I ended up ditching the use of the Interface, and all of the other issues I was having disappeared with this approach.

I didn't. If you are interested, my application is there: https://github.com/fpiette/OvbImgOrganizer

Syncplify provides free and paid SFTP servers.

For many, many years, I have used HFS. Not FTP, but HTTP. Just a portable .exe that hosts a http server that allows clients to download files and folders, and also upload. https://github.com/rejetto/hfs2 https://www.rejetto.com/hfs

There is SyncThing, an open source alternative to e.g. Dropbox, that works peer to peer. It can be run as a service on Windows or simply as a regular program. There are implementations for multiple OSes. Setting it up isn't as difficult as it looks at first, but it takes a bit of reading the docs.

I don't throw away dollars to save pennies. That is to say, I value my time more than the cost of computer memory and CPU cycles, because the value of my time keeps going up while the cost of memory and CPU cycles drops much faster.

Yes, there is. I blogged about it here: Dataset Enumerator Reloaded. The latest sources can be found on GitHub: https://github.com/UweRaabe/DataSetEnumerator. You may need to remove the class var, because the sources are to be used with instance fields. Is there a special reason for using class var?

Damn! You're right! Mixed these Germans (LOL) singing about Russians with those 😄

Why Dschinghis Khan? It is Rasputin by Boney M!

Because it has been designed correctly with ref, out and by value arguments handling the three different parameter semantics. C# is an example of how delphi should be, and the entire issue with this missing warning is because delphi is so badly designed in this area.

@David IMO you are mixing data with UI in a way that only causes problems. You should use a list class instance (nonvisual) to hold objects that represent a student, each of which holds a list of the classes taken with the score obtained. The list class can then have a method to compose the items for a listview you pass as parameter to the method. If you need that you can store the reference to the student object in the corresponding listitem's Data property, but the lifetime management of the objects is the duty of the list class, not that of the UI listview.

This is just going to be the age old issue that most Windows code expects floating point exceptions to be masked, and Delphi's RTL unmasks them. So, mask floating point exceptions when you call into Python, and unmask them when the Python call returns. Or just mask them always if you don't care about floating point exceptions. Of course, the floating point support for changing floating point control state is not thread safe in the Delphi RTL as I have been saying for more than a decade now.