Leaderboard

Sure it's down to a lack of resources. But that's a consequence of expanding to new platforms. Each additional platform comes with a maintenance cost. That cost is paid for out of revenue. The bulk of the revenue comes from customers that are using the legacy platforms. If Emba continue to neglect their core business (Windows development tools) then eventually customers will look elsewhere.

I have found the core of the issue. When a form receives a wm_dpichanged message, TCustomForm.WMDpiChanged is called which scales all components on the form. But TCustomGrid does it in a terrible way; there's this simple loop that modifies the heights of the rows: [vcl.grids, TCustomGrid.ChangeScale(), line 1735] for I := 0 to RowCount -1 do RowHeights := MulDiv(RowHeights, M, D); and in the debugger I see that this loop needs a whopping 72 seconds to complete on my Core i7 notebook (for 86400 rows). The reason? It appears that the changing of a single row height triggers an InvalidateGrid() plus an update of the scroll bars (which, incidentally, is why my breakpoints kept landing in USER32.SetScrollInfo). And all of this happens inside the handling of a wm_dpichanged message, so the message queue is blocked for ages which freezes my desktop.

Hi, Using the web interface is it possible to flag comments by certain individuals to be hidden or ignored? Thanks

perhaps, our time or money investment to FPC/Lazarus could change EMBT behavior. Skip subscription fee once, and invest it to the better cause. Let EMBT know, that you did so..

Learn how private equity firms work and you understand why things happen as they do.

@Attila Kovacs Lucky guy! All those things you rate valuable to pay for you now get for free. Much better than getting some gimmick for free that you never asked for and probably has no value for your either.

Perhaps employees. But the decision makers beeing responsible don't take the steps needed.

Yes, OnMessageis designed for this. OTL takes care that OnMessage handler is executed in the thread which created the background task (in the owner).

Sometimes it takes strength to say no to some customers.

I dispute that. I don't see anything wrong with a business model that concentrates on enhancing and developing their core market. Imagine what could have been achieved on Windows if all the resource that was used on the new platforms had been spent on Win32 and Win64? Remember also that the vast majority of the income is still from the Windows tools.

Done, https://quality.embarcadero.com/browse/RSP-24430

Inheritance of helpers is not solving the problem at all - you then still can have the case where you would want to use methods from 2 different helpers which cannot inherit from each other. The only solution is to make not only the last visible helper usable but treat conflicting methods via overload resolution - just like extension methods in C# do.

Both class and record helpers could do with a real upgrade. The lack of inheritance and lack of support for Generics is crippling.

Only us old-timers.

TApplicationEvents works by assigning its own handlers to the TApplication events. So if the IDE, or another plugin, assigns its own handlers to the TApplication events directly then TApplicationEvents will not work correctly. As it should, since TApplicationEvents is specifically designed to be used that way. When everyone uses TApplicationEvents handlers instead of TApplication handlers, then everyone gets notified of events.

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;

Hmmm... basically, the differences are not that big. The looks may differ but most control sets on different platforms or UI frameworks have similar functionality. There may be some differences between desktop and mobile, but among them, there are not that many basic differences. Sure, there will always be some that try out new controls (like the Office people at MS did and probably still do) and if they catch on, others will copy them. If they don't, they will slowly disappear again. Note that all the big vendors have usability labs, and the smaller ones can and will copy the successful idioms. Even the IMO worst of all of these, Android, is still easy enough to use and doesn't present you with many surprises. So UI controls/idioms are not the problem. The design/structure of an UI, or set of dialogs can however make big differences. I already mentioned the few very bad designs for parts of our dental software. They have usability problems because the designers/engineers don't know the proper workflow in a dental clinic. And because for such items, there are no standard controls. (Weirdly enough, the previous software we had, which was DOS-based, did some of the things we now have problems with much better).

Thank's for all. Yes, write lock - is the answer.

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.

Issue solved by rickard67 here: https://github.com/RRUZ/vcl-styles-utils/issues/242

Make a copy of (bds)\source\fmx\FMX.Media.Android.pas, and put it in your project folder. Modify this routine: function CreateJBitmapFromYuvBuffer: JBitmap; var Image: JYuvImage; Rect: JRect; Stream: JByteArrayOutputStream; LoadOptions: JBitmapFactory_Options; begin SurfaceSection.Acquire; try Image := TJYuvImage.JavaClass.init(SharedBuffer, SharedBufferFormat, PreviewBufferSize.X, PreviewBufferSize.Y, nil); finally SurfaceSection.Release; end; Replacing the SurfaceSection references with QueueSection

Does no one read Alan Cooper any more?

We all knew it would come this August, but now the Google Play store is showing warning notifications on new uploads: And to top it off, there's a new warning that I have no idea how to address (if it's even possible) with Delphi:

If so, then you replied to a comment that doesn't lead anywhere. I was going to stop after the comment. But we all know that threads do not just end like that. But telling something is off-topic and then stopping the discussion does make sense, IMO. So if you don't prolong it, it works.

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.