Rollo62

Hi there, maybe its already too late, too tired today, but I just asking myself why the code doesn't create any "blue" breakpoints steps in the Except scope anymore ? All the other function shows debug breakpoints, and I also can debug them, only if an exception occurs, this is NOT catched here. (running under Macos Catalina). I'm just testing with the new Rx10.4.2, but I need a rest now, so maybe someone can spot the issue ? function TConnector.IsDeviceConnected : Boolean; var LTxt: String; begin try try if Assigned( FDevSelected ) then //<== for exapmple, here I see the "blue" breakpointe, and can debug begin if FConnection_Last.IsConnected then //<== this mayb rais an exception, but I cannot debug it in try - except scope Result := True else Result := False; end else begin Result := False; end; except on E : Exception do begin LTxt := E.Message; //<== the whole function has "blue" breakpoint steps, only these 3 lines not S4Debug_Step; //<== this is just an emprty function all as nop() replacemnt Result := False; //<== Nope, no breakpoints either end; end; finally S4Debug_Step; end; end;

@Daniel Thanks for your intervention, but don't worry. The fact that David thinks I'm confusing the debugger and/or the compiler doesn't offend me much. At least this is my daily work I just made a fast test, introducing a forced raise before the part in question, et voila: All looks OK. So the question is who is confused most; the compiler, the debugger or myself. I will try to reproduce that in a smaller code, but I'm afraid that this doens't work. Maybe I find time to check that tomorrow.

Right, but it looks as if the compiler doesn't produce any except code here. Of course this is only blue/green colors, not code, but I assume that compiler didn't generate anything here. I have to check deeper, since I never have seen that behaviour before. Maybe there is some strange condition that refuses to compile except code ?

Yes, but I can see an exception in the IDE. I thought as long as I can see it, the compiler should be able to capture it. I think thats not the issue, I have doublechecked the settings, they should AutoSave to CrLf, and the line endings are OK. Moreover, I have no "misaligned" "blue dots", but only "green lines" instead of them in the except scope. I can follow Davids argument about anything goes, but shouldn't the compiler generate "blue dots" as debug steps anyway ? At that time there is no exception yet, but still I have no debug breakpoints. It looks like completely "dead" code, never compiled to binary: also nil doesn't make much difference

Hi there, I found this small note about your own authenticator. Is anybody using Google Authenticator for your own apps ? Maybe there is a ready-made library somewhere, that makes it easy to use. What I suspect about Google Authenticator, that his is another piece of data Google is analysing, so it always knows when and where you logged in. Together with what Google already knows, this is maybe highly problematic. But I'm not sure about the Google Authenticator, and maybe its perfectly fine, do you have any experience with it ? I want to try that out, but also check alternative, own authentication systems.

@emailx45 Thanks for your proposals, but I already checked before without the try .... finally scope, that makes no difference. But your consideration to change Assigned is maybe something in the right direction. The variable is and Object, no Pointer, so it should work as-is too IMHO. I will check again tomorrow. The whole try ... except shall catch dangling pointers, and I would expect to land in the exception scope, no matter what, or am I wrong ? If an exception raises, then it should be catched, no matter if nil or dangling ? Or are there different kinds of exception ? Again, I should note that I'm testing on Macos/Catalina, and the Macos apps have these kind of "deadly" exceptions: "Project Xyz raised exception class SIGABRT (6)" maybe they were handled differently than normal Delphi exceptions ? Maybe that is an explanation too, I have to check deeper next week.

I would propose, when 1st testing, better don't install unnecessary components. Normally I do some very pure test runs first, before I add more stuff. With that approach its easier to find the library or expert that causes issues.

Still testing, but so far it behaves very well. Feels all in all quite fast and responsive, much improved to my Rx1041. If it compiles now all my projects without big issues (and it looks like that), I would say its close to very satisfying

Thanks, I'm not sure how to check if an app calls some web services. Have you checked that its not sending anything ? To proof that sound too me like a big Wireshark setup with local proxy server, to catch any transmission. I would trust in that regard, as they have to loose a lot of reputation if they would cheat us. But the bad taste is still there, as they might change their mode at any time. I will check FreeOTP, that sounds interesting.

Don't worry, emptiness is full of everything, thats what physicist's know today

Maybe you talk about TEmptiness<T> ? 🙂

I think thats a good startingpoint too. http://fire-monkey.ru/

Easy to understand: Apple want to punish their loyal developers with maximal pain as reward 🙂 If you want to be in their exclusive club, you have to enter using their back entry veeeery deeply.

TListItemText has all properties for alignment; Align, VertAlogn; PlaceOffset You better check FindDrawable before access, call me paranoid, but I never trust any FindXxx method var Dwb : TlistItemDrawable; ... Dwb := AItem.View.FindDrawable('Text1'); if Assigned( Dwb ) and ( Dwb is TlistItemText ) then begin Text := Dwb as TlistItemText; ... end;

https://www.youtube.com/watch?v=yVwYZ05N7Sg https://blogs.embarcadero.com/introducing-the-listview-item-designer-in-rad-studio-10-1-berlin/ https://www.youtube.com/watch?v=nRPDH5dHMCA https://www.youtube.com/watch?v=il55nvYbDsg

@Jim McKeeth Sorry Jim, I do not have much time right now. What I can say in general, I think the problem with the demos is that they were not set up in a proper folder representation. Like /Packages/Rx1033 /Packages/Rx1041 /Packages/Rx1032 /Src So that all different versions are nicely separated, and no IDE .dproj conversion is needed when opening with the wrong version. I think that is usually most of the time the provblem, that opening an older .dproj file with the newer IDE, but the IDE is not 100% able to convert and all parameters correctly (its simply too complex). A better library-structure would help to keep the samples up-to-date, and also to see whats already upgraded, and whats not. I came back to this topic triggered from the nice article here. Maybe the demos has to be seen as part of the library too ( so do I ) ?

Probably by loading on demand, see here in the german DP.

I think VM on Mac is perfectly fine with their license. Anyway I payed so much for their stuff that I hardly care, I feel that I bought Apple already

Maybe its worth to share the answer in your cross-post on SO. What brings me to the question if MacInCloud is a useful tool or not ? I considered to use MacInCloud in the transistion times, when OS version changes, to fastly and safely make early tests. Now I set up my own VM, installing stuff, etc., which is no big deal, but also takes some time. What I wanted to test if just starting MacInCloud, pre-configurated, can maybe reduce these test- and configuration time a lot. I would try with real devices, so not the simulator, as the SO answer also points to. Will such setup with MacInCloud is working flawlessly and make sense, or will I stay better with my VM setup ? I'm wondering who has good or bad experiences with MacInCloud.

I'm just a little curious: Who really relies of a memory string >= 2GB, in danger of killing the whole OS ? Even if my machine would have enough memory, I always would try to chunkify that, or to use memory mapped files instead. Is this 2GB limit a rather theoretical limitation, or is that widely used in real world applications ? Of course there were maybe some special cases on dedicated machines, like math, search engines, physics simulations or the like, that would require such high needs, but I just think the normal app, even with high database or 3D load, would never reach that limit. Maybe you can proof me wrong by some examples, since I don't see any use case at the moment.

Hi there, @jeroenpJeron's blog notes points me to an old issue, thank you for keeping track on that very detailled. I wonder, from the two practical workaround solutions, which one is best: I would vote for the 1., as a golden rule: DON't USE CONST ON INTERFACE PARAM's My argument would be, that is easy to spot at first sight in the interface and implementation, and its easy possible to find by aoutomated tools. What arguments are for the 2nd solution, are there any better ?

Not really, I was thinking in the direction that in 95% of cases have NO performance issue at all, so I could judge for "safety" over "performance". Like 1. Never use const interface parameters (in most cases where a little performance loss is acceptable) 2. Always use local inside 3. Keep as-is, educate on the issue 4. Never use inplace-creation 5. Always use .New creation approach That would make 1.) intrinsically safe under all circumstances, which was my goal, on cost of only a little performance loss. Well, that makes 4.) and 5.) still very valuable and preferrable, and working perfectly together with 1.) too. All in all reducing together the whole risk of "pitfalling" somewhere unexpected.

My criteria would be an easy to spot solution, that jumps in the eye when not following the "golden rule". Of course this might be strongly philosophical, and maybe has personal preferences. Thats why I think its good to list all possible options, with their arguments, in a short list like this. So that everybody may decide for himself howto deal with it. So far I count 1. Never use const interface parameters 2. Always use local inside 3. Keep as-is, educate on the issue 4. Never use inplace-creation 5. Always use .New creation approach I think there were many good solutions on the table already, I'm curious if there were more outside. Maybe really 4.) is really better than 1.), have to think about the pro's and con's. In fact I rarely use inplace creation anyway, so it wouldn't be a big deal in my case anyway. What I use is 2.) quite often, 4.) mostly, 5.) more and more often ...

Ok, I agree on that too. So you mean "Never use inplace creation, no matter if its object or instance is used" ? Yes, the basic issue is maybe that inplace constructions are easily overseen, as it not obvious if they are used as object or interface. You always need to dive into it, to find out. But this is not 100% efficient either, I'm afraid. To use always an additional variable at caller side is good rule too, but could also lead to clumsy looking code. Maybe to get the best of both is to use special named functions, as shortcut, like Add_Obj, Add_Inst, but thats not nice looking either. The .New approach I like also a lot, and use it in many places. Yes, maybe thats solving issues, but also maybe has not 100% performance. The issue with all that I see is, it doesn't prevent or protect against accidentally using inplace creation, which the 1st solution would be able to solve.

Thats a situation where you could use fully qualified names, like UnitFormats1.FormatSettings. DateSeparator UnitFormats2.FormatSettings. DateSeparator And yes, the last Uses entry wins, but if you use it may show usually some "ambiguous" name warning, when accessing methods or fields.