domus

Have the same problem. Found a solution to this?

Imagine that meeting. Let's implement: TList: indefinite growth allowed; TStack: indefinite growth allowed; TQueue: indefinite growth allowed; TQueue<T>: indefinite growth allowed, but I propose we use "Push" and "Pop" instead of "Enqueue" and "Dequeue"! TThreadList: indefinite growth allowed; TThreadedQueue: STOP! We'll not allow indefinite growth! It's all up to the user now. Also, We'll be pushing and popping, not enqueueing and dequeueing. Also, unlike "ThreadList," we'll call this one "ThreadEDQueue." "That'll keep everyone on their toes!" Happy New Year!

I wrote "dynamically," by meant "automatically." My bad. When I tracked QueueSize when starting the debugging, I saw it grow along with the pushing of items, and by having made the mistake of believing the documentation, I thought the queue's size was growing automatically (along with the items being pushed) and dismissed it as being a possible cause. So I went down all the wrong rabbit holes. I know about Grow. I assumed, at first, that it entailed the reserved space for the queue before it automatically grew along with the pushed items, analogous to TList's Capacity property. But it doesn't grow automatically, of course, just to make life a tad more exciting. Cheers! Dom

Hello, Remy. You're absolutely right. I was assuming TThreadedQueue had dynamic size, like TQueue, but it's a fixed-capicity ring buffer, apparently. As an aside, do you know why its QueueSize property is returning the amount of items in the queue, contrary to the documentation, stating it returns the fixed size of the queue? (not that it matters, since I can keep the fixed size in a separate parameter, but it's misleading) Also, why are they using PushItem instead of Enqueue and PopItem instead of Dequeue? And, as a final question, why isn't there an option to make it grow dynamically? None of these are questions you're supposed to answer, of course, but just wondering... Thanks for making me dig deeper into this. Cheers, Dom

My goodness. The thing that was blocking everything was a TThreadedQueue. Days of debugging, just to find out this thing is absolutely unreliable inside a TTask (in the sense that it absolutely blocks the main thread when popping an item).

After quite a bit of back and forth with the o1 GPT model, it suggested using TBitmapSurface directly, like TBitmapCodecManager.LoadFromStream(strm, Surf) (where strm is the PNG stream), which it claims uses only the CPU, steering clear from any blocking caused by GPU access, but having tried that, I see no difference. Still on Delphi 11, but I could try Skia anyway. It's just that the last time I tried it, a while back, it seemed slower than the native FMX library (using D2D). Thanks!

Indeed, that's what I'm trying to find out. If it does, it kind of defeats the purpose of having it run in the background.

Does Graphics32 support FMX? Just stumbled upon Image32. Anyone know how it handles TBitmap streaming...?

Hi, I'm using TBitmap.LoadFromStream in a background thread (TTask.Run), but it appears to be blocking the main thread (and UI), since I see pauses in execution when this function is executing. It's loading a PNG into a TBitmap. There is absolutely no interaction needed with the UI. The bitmap is not linked to any component. If this function needs to synchronize with the main thread for a part of its algorithm, is there an alternative one available that doesn't? Thx!

OpenAI have introduced something that seems quite useful in getting a consistent, structured reply from ChatGPT: Structured Outputs. Is there a way to use it in Delphi, without reverting to Python? Just asking in case someone has already gone through the research, and slightly lazy on my part, admitted. Cheers, Dom

Just FireDAC, in Windows. But problem was solved in the mean time. Cheers! Dom

While the documentation site is down, would anyone know why it's a problem using an Int64 with an Sqlite database? Int64 values written to Sqlite Integer fields seem to be problematic (truncated to 32-bits). Manually changing all field properties to .AsLargeint, on the other hand, throws a "type mismatch" exception at application startup. All Sqlite integer fields are supposed to support 64-bit values. (don't bother, solved by manually using BIGINT in creation of table)

Odd. Maybe the parent was temporarily visible...? Maybe another mechanism involved. Or I should just update the library.

Can't find that method for WebView2. Deprecated...?

That worked. Apparently it's a known issue, causing many headaches: https://weblog.west-wind.com/posts/2022/Jul/14/Fighting-WebView2-Visibility-on-Initialization Many thanks! Saved me a lot of time!