Rollo62

Yes, but also names might change over time, so thats no real benefit over numbers. All right, numbers have a higher risk of being re-ordered, but in principle: "enums might change over time". Thats on reason why I prefer the conversion logic nearby, in enum's class helper itself. There I have only one point of logic, where I could even do some conversion corrections from different enum-type versions.

Yes, but that may happen too when you insert a new value in a consts list, and re-order their values to make it ordered more nicely. Exactly such cases I handle in the enum itself by class helpers ToXxx and FromXxx. Working with number ranges inside an enum, I can even implement a "poor man's grouping", like enum 0 ... 99 ==> Isgroup1 enum 100 ... 199 ==> Isgroup2 All this well supported by class helpers, with least memory footprint.

Interesting philosophical discussion. I like and use enums heavily, always with full scope and "T"-named for safety reasons (to avoid cases as in the start of this thread). Of course I know some people like the "non-prefixed" version of everything, this I think leads to many issues. On the other hand, the record proposal from @Marat1961 is worth considering too, as a good 2nd alternative. Maybe they can nicely coexist both, with their pros and cons, I won't fell disturbed too much. I see also one very practical benefit that speaks for enums nowadays: They can use class helpers. From that I make also heavy use, leading to focus code where it belongs to. I'm not 100% sure, since I never checked that, but I think class helpers won't work on consts.

Hi there, I'm considering to install npm, node.js VsCode in my VmWare 11.5.6, Windows-10 guest, same where Delphi is installed. Usually I try to keep my VM's clean, but I would like to install that because of its more convenient. Now I see that it seems to require WindowsBuildTools, or a version manager or other package manager, which are maybe conflicting with the Delphi Windows Platform SDK Tools or other parts. That should not affect my builds for Windows, IOS and Android, via ms-make, c-make, etc. I think the last time when I installed this on another VM, it was still a usuall EXE, not requiring additional build tools from MS. This might have changed now, and I'm a little hesitating installing such core build tools from MS, as a usual VS installation changes so much under the hood, that its not a normal PC afterwards. There are so many options, I think Chocolatey was my lat time favorite, but thíngs are changing so rapidly, is this still a good choice ? Does anybody has experience with installing those tools altogether, with least memory footprint and least issues ? Should I install it together with Delphi, or better in a separate VM ?

Yes, but Alexa ASK CLI seems using all this, and VsCode is part of that usually too. I will try how far I get with the protable versions, but I have read some time ago that the portable stuff doesn't register everything, as it should. Npm is mainly interesting for loading everything, and I think there were some issues when loading other packages.

Is NA some kind of reserved word or math function, have you tried with .Whatever too ?

Exactly, this I'm afraid of. To install an ecosystem, like the Alexa ASK CLI, this notes very many references, like NPM, NODE, GIT, Python, etc. in place, and seem to prefer to re-build everything from sources as the proposed setup. I'm afraid that a portable version is not integrated that well, and causes other issues with the tools. Maybe this problem arises from Windows, which has not the basic build-tools available, while other "...nix" based OS have them on-board in every standard installation. I have to check further, what combination is probably best on Windows, with least impact. Maybe I try some tests in a snapshot of my Delphi VM, and check whats changed and going on, before I confirm it.

I use a structure like this, not only for variants, but also for Updates Packages\Rx1040\PrjVariant1 Packages\Rx1040\PrjVariant2 Packages\Rx1040\PrjVariant3 Packages\Rx1041\PrjVariant1 Packages\Rx1041\PrjVariant2 Packages\Rx1041\PrjVariant3 Src\ Src contains all common units. PrjVariantX contains only the different .dproj, .dpr in the best case, but may also contain certain bug-fixes to system units or other special units needed ONLY under that specific configuration.

Hi there, I'm sure most of you were aware of @Dave Nottage and his very helpful (live-saving) Kastri(Free) projects. Now with the presentation of the Memorizer, there are certain discussions about issues in the cross-platform world. Same as Dave I try to postpone permission requests to the bitter end, just before touching the hardware. For camera, sensors, etc. thats usually no issue. The problems may start when using local notifications, or related permissions, like Bluetooth and location. The local notifications permissions are fired right at startup, and thats annoying. You can imagine if you need a few permissions at startup, then they all will appear, and the user has to click them away before showing any useful screen. But for local notifications permission this might be maybe the right way too, because in mobile you also can run in foreground or background. So I would like to discuss the possibilities and pros and cons we have, for the permission settings from a users point-of-view. 1. Ask permission right after startup (as is now) - this is annoying to the user, especially if several requests appear one after the other - works in all cases, also for background mode, as it forces the user to decide - its a little like the old "Android way", permit all before use anything, but Androids style has changed meanwhile (for good reasons) - sometimes the app runs in background, and has no other chance to notify, than by local notification So the local notification permission shall be given at startup, to ensure this works. 2. Ask permission short before usage (in foreground) - thats what I like too, users shall decide each function before they use it. - but when moving to background w/o giving permission before, this might fail. A user cannot give permission while in background mode, the function simply fail or crash. 3. Ask permission short before going to background - this is not possible, because the app cannot do much when changing the states, especially no long-lasting alerts. 4. Allow permission in a special setup dialog - This is the "windows" setup philosophy, I think very much out of fashion in mobile: Force the user to visit setup first. - This will solve the issue in 2.), but I really try to to avoid this forcing of "setup" style design. Are there any other ideas or use-cases ? So far I think 1.) (as is) has its need too, and its not easy to cover all use-cases with one solution in mobile, there are too many options. Beside that, Android and iOS might have different philosophies as well, howto get them all under one umbrella ?

Thats what was proposed in some places, it seems to me that they want to prefer compilation over setup.

@Dave Nottage Hi Dave, thanks for your nice article about a major problem in the Apple environment. Yes, Apple always keeps us busy with such unnecessary work. Since I had fallen into such nasty boobie trap in some older version before, I changed my way howto deal with these updates. So I may provide another (pseudo)-solution to this topic: Solution 3: ( prerequisites before starting any update ) Use your XCode environment for development in a VM virtual machine, like VmWare Fusion Make a backup of your VM image, BEFORE any update of the VM (if you prefer snapshots, thats fine too, if you cleanup later, but I prefer to make complete, FULL clones of the whole VM) In the VM backup also the current SDK's are backed up of course, if you ever need them again later With these FULL clones you can switch fast and easy between older and newer XCode, SDK and PAServer setups That doesn't solve the basic problem, of course, but makes it much easier to handle different SDK environments, in case of any "crash" might happen wit the new version.

Not yet working , but I haven't tried again. Im working on a real Mac Machine right now, But Ive downloaded VMware 12 already, and will try soon. Sometimes such issues disappear suddenly, I hope...

Yes, right. type UIntPtr = NativeUInt;

Wouldn't be the NativeInteger the right cast for a pointer ? Matching the right bitness on 32- and 64-Bit machines, to the same pointer bitness ?

I'm afraid you had the ESP8862 in mind, as far as I know the ESP32 boards lay around 5$. But you never know what quality to expect from different suppliers ...

Hi there, I need to choose a basic type for caching and manipulating binary data, which is mostly represented as String, but could be also pure Byte data. The problem is that I need to analyse, chop, copy, append, re-combined to this buffer into several places, and finally the data will be string in most times. The original source is TBytes, so my first consideration is to keep TBytes as buffer data type. While the original data mostly contains ANSI strings, but in some cases maybe also contains binary (Byte) data, 0 ... 255. In short, the basic question is maybe: With original source data as TBytes - Keep TBytes for buffer manipulations, and convert in different places maybe later convert parts to string, or - Immediately convert all TBytes to e.g. String, and use string for manipulating data, even if maybe some of the data may be binary. TBytes: But from my gut feeling I would say that TBytes is probably not the most efficient data type for handling data, since its dynamic handling is not supported very well from the compiler. There needs to be done a lot of pointer tricks and memory move's to make that efficient. String: Strings on the other hand are very efficient and optimized, using all tricks like copy-on-write to make them fast and easy. I use them in many paces and they behave always very good and very efficient. But the drawback is that Strings are Char-based, which should double the memory footprint compared to Byte. What will be the right codepage for the encoding then ? RawByteString: The alternative RawByteString is not recommended, only as replacement for older AnsiStrings with codepage issues. So they have clearly another use-case: AnsiString: (without specific codepage) I could take AnsiString without codepage as base class, which would possibly reach the same efficieny as strings, but as AnsiString was deprecated and removed once from modern platforms, this leaves a bad taste. It seems that I came back only on massive complaints from the community. So my current decision tends more to use pure String as base class: type BufferType = String; var FBuffer : BufferType; ... //<== Single point of source data procedure SourceData( AData : TBytes ); begin FBuffer := EncodeAsASCII( AData ); // use no specific codepage, or DOS-like, to simply use Byte (0 ... 255) as elements ... // FBuffer copy, move, indexof, concat, ... //<== Further processing on FBuffer with effective string routines end; Is that the right decision, ignoring the doubled footprint in favor of speed ? So which option to choose from, A., B., C., or maybe I have overseen even another possible option ? I hope that you can help me with that decision.

I agree on the ugliness, but what if type extension is too hard to get ... What else is on the roadmap ?

Would be great to support at least kindof casting to the desired helper, that would solve some cases where several competing helpers were all around.

Great, that you support Firemonkey. Would be very helpful to see any visual impression of the FireDocking in action.

Have you upgraded the project from Rx0.3.3 ? Maybe there is still the Compiler option "Generate iOS universal binary" somewhere in the .dproj file, or other settings have been wrong. If the project worked before, then usually I recreate my .dproj files, to get a clean .droj setting, especially after larger version upgrades like 10.3.3 to 10.4

@TurboMagic Thanks, I was not aware of that feature. Found this here from Marco. But I'm working with TBytes as parameter, not sure if that should also work. So far I'm using manual pointer operations. Have to check how that is done and look into its performance, maybe only next week.

@Erik@Grijjy Great stuff, thanks for that. What is your next project, are you going to implement similar structure to the JSON parser ?

@Der schöne Günther Depends on what you need, the HtmlComponents are a complete RichEdit-like Editor, and ends up as complete reporting solution. with all the possibilities it should have (scripting, interactive options). So it can create and display the HTML, if you need that, so e.g. for translations the app could be switched into "trnanslation" mode for special users. Anyway, for a pure display webbrowser is fine too, but David asked for "components" explicitely, so I think they are a good choice. On the downside you can see what happens if TWebBrowser-support is broken, as it was in some older versions and for other platforms, or now the messy change to Edge browser. Sometimes its good to have your own viewer in the backpack.

I would recommend those HtmlComponents, they can show HTML nearly as good as a webbrowser.

Very good, the Python4Delphi community gains traction 👍