Rollo62

All these seems to be related RSP31014, RSP31049, RSP31086 No official statement yet, maybe upvoting helps to accelerate that. The "debugserver" issue I see from time to time, which IMHO seems to be an XCode issue. So far there is no good explanation howto handle this, except to update phones and XCode to latest versions. This I try to avoid mostly, to not run into such booby traps. But I think at least the "debugserver" issue might get fixed by updating from time to time. This always looks rather like a "planned obsolescence" for the API from Apple, than a really technical issue. Not sure what philosophy Apple really has regarding their updates, so far they seems not to care a lot about their developers, as I can find many similar issues in the XCode world too.

5 years old ...

Just to clarify that. What do you mean excactly by "check every change" ? I usually make changes, check compile, and decide more or less depending on the amount or complexity of changes or their locigal completeness, if I commit or not. If you mean to commit only code that compiles, yes I do the same. Or do you mean to commit only after complete tests, UnitTests etc. ? There are some voices in the web that recommend to commit every little step in GIT very frequently, as a kind of "undo" function, but I'm not working that granular yet. I always tried to do more commits, but my reality is that I commit more complete logical tasks, which are more like medium or larger transactions in code. What level of granularity do you recommend for commits in your note above ?

Probably like that, with full control over address and data bus (only with 3 bit data bus). Simple operation, one switch at a time, switch 1 = 1, switch 2 = 2, switch 3 = 4 (WHAT ??) While the "0" in those days was considered to be "AI", based on fuzzy quantum states. Until then: This (not further known) person invented the "0", to be used in a computer: From that day the real 3-Bit computer was born, and could made first calculations: switch 1,2,3 OFF = 00 switch 1 = 1 switch 2 = 2 switch 3 = 4 (still nobody knew what was going on here, it should be 3, well who cares) switch 1,2,3 ON = 007 That was the day, HE, SHE or IT was happy, and called it SUM-Day. (Later the romans made wrong translation, we call it now sunday).

The 0 took a long way over centuries. Maybe HE was not aware of that when HE created the world in 7 days.

procedure TForm5.BitBtn1Click(Sender: TObject); var ms1: TMemoryStream; fs: TFileStream; ms2 : TMemoryStream; FilePath: string; begin FilePath := 'C:\weekcpdf_tech6.bin'; ms1 := nil; //TMemoryStream.Create; //<== double Create ms2 := nil; //<== missing prepare ms2 fs := nil; try ms1 := TMemoryStream.Create; //<== double Create fs := TFileStream.Create(FilePath, fmOpenRead); //<== I would check if fs valid here fs.Position := 0; //<== I would ensure Position 0 here ms1.CopyFrom(fs, fs.Size); ms1.Position := 0; //<== I would ensure Position 0 here ms2 := TMemoryStream.Create; ms2.CopyFrom(ms1, ms1.Size); //<== I would check if ms1 valid here finally FreeAndNil(fs); FreeAndNil(ms1); FreeAndNil(ms2); //<== missing free end; end; Just some obvious observations from fast overview ...

To put something in a thread and hold the main UI thread until its finished , that makes not much sense IMHO. Then you can also proceed everything in the main UI, its the same effect. A task should be running in parallel.

@Stefan Glienke The BOM fix is a perfect example of what Im talking about. Not too many functions in one class, but a class that does its job right.

So the circle closes to @pyscripter s solution of Bom Handling, Which makes a Lot of Sense to me.

@Lars Fosdal Well thanks for that. One more argument for me, why I'm thinking of even TStringList as interposer: I NEED a real good TStringList, doing all the basic jobs. I really don't like to have a TStringListF for right file handling, a TStringListS for right stream handling, a TStringListKV for right Key/Value handling. This is too much name cluttering for my taste, and usually not very necessary to me, better to have one TStringList that fixes it all, and provide all basic, COMPLETE functionality. Most issues I have that classes don't were designed completey, and important parts were missing. I hope you get my point, just my 2 cents, why I think of interposers more than I should. And yes, we can derive a TStringListEx from TStringList, as the new and only perfekt child (maybe).

Yes, sorry for that. But its interesting to see that the world is divided into design time component lovers, and not so much lovers 🙂 It still has a bit to do with the gerat TStringList component ( I hope ). At least we all agree that this is the right way to go for this, as a new, derived class.

Hi there, I used to include a custom UserTools.proj file in the %APPDATA% folder, where some general project settings are defined. That file does not do anything harmful, only provides some global defines <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <DCC_Define>FrameWork_$(FrameworkType);$(DCC_Define)</DCC_Define> <DCC_Define>_X_USE_$(FrameworkType);$(DCC_Define)</DCC_Define> <DCC_Define>_X_SHOW_EXTENDED_HINTS;$(DCC_Define)</DCC_Define> </PropertyGroup> </Project> This file always worked very well, since many versions now, but just I see that the following happens reproducable: Closed IDE, I copy the UserTools.proj to %APPDATA% I start the IDE: UserTools.proj is still there I open a blank project: UserTools.proj is still there I do a project clean UserTools.proj is gone I have installed only TMS WebCode, TMS FNC Components Have never seen that cleaning a project might remove something from %APPDATA% folder, is that a new bug, or maybe something else is wrong. Maybe someone has a clue what happens here, would be very grateful, before I have to change all my projects ? Edit: Maybe I must add that I was testing on iOS currently. Have to check the behaviour on other platforms too, but I think it should be all the same.

@Dave Nottage Happens since I've tested TMS components, at least I haven't noticed earlier, maybe I have to unload them. Up to now I have just a bare Rx10.4.1, except TMS and yes, TestInsight.

I have seen such behaviour when I tried to include functional code (with implementation section) from one file (.pas or .inc, doesn't matter),into another .pas file. Instead of integrating this as a whole into the target file, I could not separately debug this, got a similar error and a non-editable file. If I remember right, I could compile that, only opening the file while debugging caused the issue, but not sure anymore.

@David Heffernan More trouble means I have to make all these components work in the designer now, I think there is no neat trick w/o registering them. Also they are no more compatible classes, which could be used as "Xyz is TButton".

I don't see any stability issues, thats why I carefully added more and more interposers with such fixes. But what would be the alternative, to have a separate layer of self-defined components, on top of the existing ones. That would basically do the same job as the interposers, but would cause a LOT more trouble in designing the forms. Maybe it depends much on how your current workflow is. I mostly use component designer for fast (RAD) visual definitions, a few Events maybe for early testing sometimes, but mostly I do the coding via interposers and their wrapping around events, by adding their own anonymous methods. That way RAD is for design, and interposers serve for easy to use runtime coding the business logic. I agree this gets maybe difficult when it comes to BPL, DLL, etc., or binding statis DCU from other sources. Happily I don't have to do that, but if you work a lot with 3rd party components I would be more careful. Even then, when you keep your units capsulated from external DCU, that should be still OK, only the mixing might crash. I also try to divide my units into smallest possible fractions, to ensure that de-coupling (which not always works that easy).

@Stefan Glienke @Dany Marmur Thanks for your considerations. I use interposer heavily on components, to fix and enhance their behaviour. Sometimes I think even thats too much, but everytime it turns out that they behave so well. From that fact comes my dark consideration to use them elsewhere too, from time to time. My thoughts were about enhancing existing units and frameworks, by simply dropping an uses entry, which "auto-magically" can enhance the units functionality, without too much (or any) reworking of the whole unit. But sure, I was afraid of all that "side effects" too, thats why I didn't use them on RTL classes right now. You're arguments are right, so I won't touch them, and stay on the safe side.

I like useful enhancements to such basic classes very much . But as always I ask myself, if its worth a separate class, or would it be better to have an interposer class for the new functionalty. With such basic class I'm not very sure if such interposer would be good or bad animal, maybe there could be hard issues when mixing with original, static classes. Since I basically compile all code from sources, I'm quite relaxed, but this could lay the ground of nasty problems. What is your opinion, about when to use interposer classes, and when better avoid it ?

If its a new project, then its still time to change to FMX.

Do you know that FMX instead of VCL basically has maps for iOS and Android included ? In a new project, maybe FMX makes sense for you too ?

Ok, thanks. So when to you estimate that version 4.3 be ready then ? Is it worth waiting before I start my Rx10.4.1 tests ?

@Alexander Sviridenkov Looks very cute. From which version can we see that feature, is this already in 4.2 ? Never sure how I get the latest registered sources, will you send a mail, shall we re-load from latest URL ? Since I'm going to test Rx10.4.1 soon, would be good to get the latest version.

I don't expect to see many VC, GNU, QT related questions here anyway. So all the C++Builder issues were discussed in this forum already, I see them here and then. So it would not change much IMHO, only to have a dedicated place for C++Builder. BTW: Can the users in this forum hide complete categories ? If so, all the C++ haters could simply switch that category OFF. That would even get less noise to them.

I would add still some more reasons: 4) @David Millington is working so hard to find ways in better integrating and interacting C++Builder with the Delphi eco-system. We all should honour his effords to flatten the ways to C++ by opening a sub-forum here too. 5) The Delphi ecosystem might gain from C++ in many cases too, like compiling & binding C++ libraries and make it available in Delphi. E.g. where speed or other concepts are an issue, Delphi might be UI and C++Builder might provide the core logic. 6) Divide and conquer 🙂 Together we might be stronger than alone. Edit: Some more ... 7) Component suppliers face often the issue to make their components available to Delphi AND C++Builder 8.) Maybe C++ developers see how cool Delphi is, and some might change from C++ to Delphi 😎

@Daniel Well Daniel, no problem for me. Lets open a new site then