Leaderboard

Ah...beauty. That comes at the very end of the process. Usability should be main concern which will result in an overall positive UX. Beauty is just glitter and bows and ribbons. Good usability, however, is measurable. Alas this process of measuring is time and resource consuming. Not many managers are willing or even capable of spending money on this, reckoning that usability will improve itself over time. Sadly, more often than not the opposite happens.

Yes, exactly. It needs a write lock, not a read lock. Yes, you are wrong. A read lock allows multiple threads to read shared data at the same time. A write lock allows only 1 thread at a time to modify shared data. Since you are modifying data (adding a new string to the TStringList, thus modifying its internal memory array and its Count), you need a write lock. You are getting an AV because your read lock is allowing multiple threads to modify the TStringList at the same time, trampling on each other's toes, so to speak.

My gripe is not with whether it looks pretty or not, but whether it's usable at all. To get back to the original post's topic: A visual clue that a control is read only, would be nice. But Windows 8 and later 10 ruined that (and that's far from the end of the visual catastrophe these versions introduced). Or take web sites: It used to be that links were easily recognizable with blue text color and underlined. The first thing that disappeared was the "ugly" blue color. Then web designers also removed the underline. Nowadays you only know for sure that something is a link when you click on it. Or one example from non software related design failure: The controls for a faucet (Deutsch: Armaturen) used to show with a blue or red dot that was easily visible whether you turn on cold or hot water. Today these dots are still there (not sure whether that's required by law), if you either know where to look or crane your neck to find them. Apparently somebody decided that they spoil the look of the thing, so they are now hiding them. I'd like to know how many people accidentally get burned because of this.

Hooking events in the Delphi IDE is dangerous, as you never know whether there already is another plugin that uses the same event. I tried to describe a way to make that process a little bit safer and blogged about it: https://blog.dummzeuch.de/2016/03/28/safe-event-hooking-for-delphi-ide-plugins-revisited/ But it's not just other plugins you must be wary about. New versions of the IDE might also start using previously unused events. E.g. Delphi 10.3 is now using the previously unused Screen.OnFormChanged event, but only within the Options dialog. This broke some of the GExperts enhancements to this dialog and those dialogs opened from there, in particular those for the path edit dialog.

I would think Add is a Write Operation, not a ReadLock ..

Fortunately. Engineers might think they are the perfect designers, but they aren't either. And it is usually management that wants something flashy, not the designers. A good designer will improve what the engineer does, but this only works if they work together. FWIW, the client is not entirely clueless either. They know their domain. So they should be involved too. I know a few pieces of dental software that could have been vastly improved if a dentist, or even better, a dental assistant, had been involved. The workflow for the assistant would have been much more efficient.

@Attila Kovacs I gave it another go, and it does indeed work. Don't know what I did wrong the first time I tried... I also tested if multiple TApplicationEvents can be used simultaneously. This also works well. Thank you!

Works for me: procedure TTestWizard.OnAppMessage(var Msg: TMsg; var Handled: Boolean); begin if (Msg.message = WM_KEYDOWN) then begin Beep; end; end; constructor TTestWizard.Create; begin FAppEv := TApplicationEvents.Create(Application.FindComponent('EditWindow_0')); FAppEv.OnMessage := OnAppMessage;

Note that the SQlite3 version embedded with FireDAC tends to be updated at a slow pace, and stick to the Delphi release. It is currently 3.23.1 in Delphi 10.3, whereas the current is 3.28. With an OpenSource or third-party solution, you may be able to update SQlite3 without upgrading the compiler. I have seen requests to upgrade SQlite3 for regulatory or security reasons. 3.23.1 is known to be vulnerable, as reported e.g. by https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html and https://www.zdnet.com/article/sqlite-bug-impacts-thousands-of-apps-including-all-chromium-based-browsers/

It's not obscure if you realise that Longint and Longword map to the corresponding C++ types long int and unsigned long int whose size is determined by the platform ABI.

Ay, there's the rub: Please! Pretty please! Find me a good designer! When they are not even present in most of the leading UI manufacturers, surely there must be some kind of global shortage. I am painfully aware of the fact, that an engineer will fail at creating a good UI as well. So the best thing is to have them both talk with each other through the entire development process...a costly thing. *sigh*

It makes no sense to me, I just reviewed the edition matrix found at https://www.embarcadero.com/products/delphi/product-editions. The community edition has support for mobile platforms and MacOS, but not Linux. What makes MacOS different from Linux....oh yeah, the fact that it has desktop market share. So you can develop a server process or a full GUI application for free for the Mac (albeit 32 bit right now), but you have to pay the big Buck$ to develop a server application for Linux, the one platform where developers tend to employ FOSS rather than commercial development tools. If EMBT trusts that their community edition license works, why not include the Linux compiler in that edition? At least then, developers who want to target linux can see how well the tool works and buy it when their project gets off the ground. The community edition is meant to bring developers into the Delphi ecosystem. Without GUI support, a limited number of Windows developers are going to target Linux, and without an entry level edition, no Linux developers are going to try it. EMBT's Linux investment is probably minimal compared to other targets, like Mobile, yet the only way to try it out is with a trial edition. If trial's worked so well then why did EMBT publish the community edition? Delphi needs to provide a fully cross platform desktop solution or it will lose further market share to the likes of C# and it's community edition.

Yes, you are wrong. If you have two threads reading then they are not synchronisation with respect to each other.

@Uwe Raabe The file is read-only. So unfortunately, the EditorViewModified event will never be triggered. I got it to work. Here is a high level overview of how it works, in case it might be of help to someone else: I react to the INTAEditServicesNotifier.EditorViewModified event. This is triggered whenever a new editor window is activated. Here I can easily detect whether the source file is read only or not, using EditView.Buffer.IsReadOnly. The trickiest part was then getting the handle of the editor control window (TEditControl). The Open Tools Api provides no functionality for that. It does provide you with the IDE's TCustomForm though (INTAEditWindow.Form). With the form you can find the editor control by searching for a child component with ClassName = 'TEditControl' and ComponentName = 'Editor'. Instead of working with a Windows Hook, I just added a handler for Application.OnMessage. procedure TEditorNotifier.ApplicationEventsMessage(var Msg: tagMSG; var Handled: Boolean); begin if (Msg.message = WM_KEYDOWN) and (FEditControl.Handle = Msg.hwnd) then begin // magic happens... end; if not Handled and Assigned(FPreviousMessageEvent) then FPreviousMessageEvent(Msg, Handled); end;

An alternative is mORMot, its core is based on SQLITE3, you don't even need the external sqlite3.dll - you statically link the .obj file into your executable. note: you can use the sqlite db functions alone, without using its excellent ORM layer or the http/rest server modules. But I suggest take advantage of it's ORM for CURD - it'll save a lot of your time! https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITLE_142

Not only IT-designers. It's designers <period>. Show me an unusable product and in 90% it will turn out that it was perfectly usable when the engineers finished. And then the designers ruined it. There used to be a credo "form follows function", but today it's "it doesn't matter whether it works, let's make it flashy." </rant>

SHOULD being the figurative work here. There has been NO announcement from Embarcadero since August 2018 about how they plan to address the Android 64bit issue. There has been NO announcement of a new Delphi version in the works to include a 64bit Android compiler. AFAIK, there is no beta at this time.

I just spent two days debugging an innocently looking piece of code which works correctly when compliled with Delphi Win32, Delphi Win64, FPC Win64, FPC Linux64... but not with Delphi Linux64. The reason was that the Delphi Linux64 compiler for some obscure reason has SizeOf(LongWord)=8... Well, I had to look at the Delphi 10.3.1 help file, which has the following sentence: "Platform-independent integer types always have the same size, regardless of what platform you use. Platform-independent integer types include ShortInt, SmallInt, LongInt, Integer, Int64, Byte, Word, LongWord, Cardinal, and UInt64." Damn. Then I scrolled the help ten lines up and... "The platform-dependent integer types are transformed to fit the bit size of the current compiler platform. The platform-dependent integer types are NativeInt, NativeUInt, LongInt, and LongWord". Confusing, isn't it? The FPC at least is consistent.

https://stackoverflow.com/a/1395915/587106