Rollo62

Good luck. So this means the changes work at least fine for a short period now ? So I thought your original issue should some kind of reproduceable, or was it more or less unpredictable ? Nevertheless, I think that permanently re-ensuring that you really want to stay wake should solve it, since that starts a new wake session hopefully.

I think its no problem to re-start a WakeUp several times, e.g. by timer every 10 sec., to keep it alive. The user won't notice this.

Probably the deprecated FULL_WAKEUP or the ACQUIRE_CAUSES_WAKEUP could cause problems. https://developer.android.com/reference/android/os/PowerManager#FULL_WAKE_LOCK Do you really need to wake up the screen fully ? This seems to be a function that may stress internal behaviours much, I usually start the screen manually and keep the screen awake then, that works OK.

I reworked TListView a lot, but maybe that helps for your case: https://stackoverflow.com/questions/37570047/change-alternating-colors-in-firemonkey-tlistview https://github.com/rzaripov1990/ModernListView

Maybe thats not a complete solution either.

You could consider CustomFormat with Livebindings, but I cannot really propose Livebindings. Thats workable, but has many other issues on the road too. If you want to use it, I would propose to use LB from runtime, see Steve Balls nice archive here.

Yes, I understand all your points, and totally agree with you. Only there I think that this class should show me some "blob" space on the screen, with presentation of the underlaying informations, that not really matters what kind of data that is. I don't want to choose from 20 versions of this edit, to just make it look as it should. Ok, there were limits. For example with chemical formulas or math formulas, I would consider a specific derived type probably

Yes, but maybe this has something to do with peoples expectation. Probably you are right, and the cast can solve this case. However, I maybe have a too high expectation about what a "normal" TEdit should be able to do, so I like to enhance this functionality to an acceptable level. For example, take the simple TDateEdit, which should nicely jump from yy to mm to dd. With that expectation of TEdit I would not need a bunch of "TNumberBox, TCurrencyEdit, TDateEdit, TTimeEdit, TIpEdit, TIBAN_Edit, etc.", it will be all in one TEdit. The formatting of display text is very basic task for me, and it should be solved once and for all. Anyway, I like philosophical discussions, but I understand also the reasons why others might don't like that idea. But I'm crazy enough to go my own ways, if I needed to

I like when interposer make default controls really usable, instead of new control, needed to be maintained, etc. But that is a philosophical question maybe.

You could use and interposer for TEdit (or TNumberBox), which could handle the format display. In this example as external event, but I would do this already inside the interposer as default version, controlled by format strings, as there is a quite general need for a custom format control. http://delphiaccess.com/foros/index.php/topic/13610-currency-edit/

@Stefan Glienke Well Stefan, it seems we had similar thoughts, as I presented my "poor man's" solution some days ago. Congratulations, of course you had that full fledged IDE tool ready, probably doing a bit more and different than that. I have to look deeper into it, but however the charm of my approach is that I don't need to install any helper at all.

I think Marcos proposal to change the projects default settings would be a possible solution (workaround)

My version, is portable. I have installed it on a notebook

You can reach and thank Brian here @blong directly, so he will be aware that we all love his work ( and sessions he gave ). Looking forward for more of that interesting stuff in the future.

Hi Dave, thanks for that, always one step ahead 👍 I just briefly looked into it, I wonder if it would be possible to intercept the texture stream, and if so where its best to do that ? Beside facedetetion, I find it much more interesting to implement own filters in the image stream on the fly, and to put features and drawings on top of the preview video. I'm not sure if any FMX control can be above the Camera preview, but shouldn't that be possible with the updated Z-order in Android ( in iOS too ) ?. So far I'm not sure where the textures can be intercepted. I find the (for Android) FSurfaceTexture: JSurfaceTexture; FSurfaceTextureListener: JTextureView_SurfaceTextureListener; which leads to the assumption that this could be tapped somehow. Just checked the Andoid part, not sure about iOS, but IOS was more performant anyway. Would be interesting to know if you are also work on such kind of image-processing for video stream from the camera ?

Hi there, I want to show you my approach how to organize and ease modular designs. Usually I like to have one main access unit, and all much granularized sub-features distributed in separate units. The main and sub-units build a kind of tree of functionality, where each unit can stand alone, but usually all units are highly related between each other. To access and open those deeper layer units is usually much of a click-drill-down the unit tree, or a lot of search and select via search function or other tools. Here is the general layout I like to use, which has a lot of advantages for me: unit My.Thing; interface uses My.Thing.Intf , My.Thing.Factory // // , My.Thing.Impl // QuickAccessUses // , My.Thing.Events.Intf // , My.Thing.Events.Carrier.Intf // , My.Thing.Events.Carrier // , My.Thing.Common // , My.Thing.Features // , My.Thing.Features.Factory // , My.Thing.Features.Impl // , My.Thing.Feature.Intf ; You can place the cursor on the unit names, even if its inside of a comment, and with right click "Open file at cursor" you can directly open the desired unit. The advantages I see from my point of view: - a single point of access, for a larger structural, modularized tree - immediately all of the close-related units are visible on the screen - directly see the kind of structure, maybe leads to further unit refactorings - it is a most easy and fast way to find and navigate to the desired unit, and to open it - no tipping of unit names into searchboxes The disadvantages: - None ( except putting some extra lines in comments ) I like this a lot, and this works only due to the fact that "Open file at cursor" works also within comments. Thats why I want to ensure that the Embarcadero team is aware of this, and never is going to change the open behaviour in the future editors

Not sure about waht you need to do, TL;DR; but why not exchange TThread.Synchronize(TThread.Current, to TThread.Queue(TThread.Current, For a simple notification in the UI, like a Label text, that should be good enough, and decouples much better.

Hello Uwe, I've recognized this "RAD Studio-Demo Kit/10.4.2-demos/EdgeView/" on GitHub before. Maybe you can explain how that is related to the normal RadStudio demos and samples ? I would have expected that this is integrated in the normal demo and samples files, what is a "Demo-Kit" anyway ? Maybe these were samples some kind of "on hold", until the major version jumps to 10.5. Only then this is hopefully integrate in the normal samples section, where its easy to find.

Yes, I'm not saying this is the only cause, only one possible reason. Its a little unpredictable when its happening, usually starting new Units work mostly fine, until a certain point.

I think its related to the complexity and separation of your modules. I mean small, well decoupled units: works fine and fast large, much coupled units: works sluggy, slow, sometimes cannot resolve Thats just my feeling, I cannot realy measure, but decoupling is generally a good thing (also for class design).

Yes, thats better supported by Android. But it is not recommended way by Embarcadero, due to the fact that there may occur some incompatibilities to Rx1042 libraries. Its worth a try, if you don't use special Android hardware and features, but in case of issues it may be hard to solve either.

Maybe its just an optimizing issue ? for i:= 0 to 1 do for j:= 1 to 2 do if i+j > 1000 then //<== This can never be reached, or am I wrong ?

The irrational "Confused debugger" cases seems to move on, its now the third one in short time with Rx1042. Definitively worth to look deeper into it. Maybe we have to wait until patch 1 is online ?

But "responsive" in webpages means that it might look different and "optimized", depending on the different platform. Desktop maybe 3 columns, tablet maybe 2 columns, phones maybe 1 column, and also differing portrait and landscape. "Responsive" doesn't necessarily mean cluttering something, but the contrary. Nowadays I see a kind of "perversion" of the responsive design very often, maybe from mobile first approach: Only 1 column mobile design for a phone, no matter if on desktop HD or 8K. I would call it "mobile only - mobile anywhere". You always have to scroll 1 colum stretched, with gigantly large images infinitely, where you dont see the end of the tunnel (bottom). That is IMHO similar bad design to cluttering, only to the extreme at the other side. It makes much sense to change the mode of display, depending on where your running at. (without cluttering and over-simplification)

Get well soon, and don't jump on every skateboard from your children, that you get close to