DelphiUdIT

It's useless. Lazarus approach to Android is totally different from FMX. You must rewrite all your code. And I don't know if last Android api level 33 are supported ...

There is not only a problem of the length of the "pointers" but also of the arrangement of the data within the record. The compiler "fills" the record structure with zero bytes to align the data to the defined alignment (which can be the standard one or one defined in that section of code). Therefore, the transmission of that data (whatever it is) is still at risk even if it were performed within programs made with Delphi. A change of alignment (even the standard one) for example between different platforms or different compiler releases could lead to different results.

I haven't seen any blogs or public news about Rad 12 Beta (Yukon) yet (except directly from Embarcadero). This is the link where Dave reports some important news: https://delphiworlds.com/2023/09/yukon-is-coming/

"MS_SMART_CARD_KEY_STORAGE_PROVIDER" is useless with smartcard. All the smartcards I have used are not read through that provider, but only through their own provider, which can be listed via CNG (CryptoApi Next Generation). So far I've only used Common Name (CN) access without using the password key for my purposes, and I was planning to move forward to specifically use a smartcard with Indy (but obviously it could work for ICS too). But time is running out and I don't know when I will be able to continue.

It has little to do with the topic, but with the entry into force of the DMA (European Digital Markets Act) in Europe the automatic login of applications linked to a particular account will most likely be changed. It seems that when you start the application you will be asked for the account to use for that application, effectively eliminating the possibility of automatic login. So if a "CreateOleObject" is executed, further operator action may be required. All this is a hypothesis for now, we are waiting for what and how the service provider companies (such as Microsoft for e-mail for example) will implement everything. https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/digital-markets-act-ensuring-fair-and-open-digital-markets_en This is relevant in my sector (industries), because all activities should be automatic... let's hope that the changes do not imply a distortion of the authentication logic.

Thank you, Daniel, for your commitment to the forum. Delphi-PRAXiS is truly a place where you can find professional advice and members are always available to resolve other people's doubts and problems. Happy continuation in your career.

I used Zeos with Delphi 11 only for test purpose (vs. Lazarus). But I didn't find any issue. I don't remember what version was (7.2 or 8). Reading on Zeos forum seems that is compatible with Delphi 11. Try to download from: https://github.com/frones/ZeosLib

May be FastReport is not available for Community Edition.

You can put your program in AUTOSTART folder, and every time the program start filter the Windows events log (like others told). Sometimes (for example every day changes) filter again it. Take care that if you want to start the program for every accounts you should write some records in the Windows registry. Alternatives is that you capture the message events (like QueryEndSession and similar) to capture in realtime whats happens You must take care of user multisessions and also terminal server (or RDS). Bye

This appears to be an issue related to "overwriting" of memory areas. Another tip: try disabling the "support high-entropy 64 bit address ..." item in the project options (Delphi compiler / Linking). P.S.: Do not attempt to redefine the methods, they are already defined in the indicated unit that comes with Delphi.

None about this, but I want suggest to use the WinApi.Wtsapi32 (It is the wrapper distributed with Delphi 12). It's a little bit different from yours.

It's not so simple, if you look only at one piece of "system" yes it is very very simple, but not really if you look at global system. I make systems where different manufacturers participate and obviously each of them has no problems with themselves. It's when everyone has to talk to each other (I mean the systems) that problems arise. One makes versions 1, 2, 3 over time and each of these is not compatible with the rest of the world in their respective versions. It's like if you do Windows 11.1, 11.2, 11.3 and ALL third party applications have to be totally remade for each version (and not for improvements). Operating system, email, text editor, etc... all software versions are different. And in the industrial sector this causes quite serious problems: every time something is changed the entire system must be validated again with considerable costs and resources. Try to think if a system made a "braking control" pass off as good when in fact it isn't....

However, it may be that the focus of the foreground window is not yet active when the program generates the key sequence. The fact that it works during debugging and that in normal runtime it doesn't, makes me think so. Try putting a sleep(1000) after the SetForeground. Then maybe decrease the sleep...

The same for me. The servers are in vacation

I used and currently use styles. I customized two styles and since years I use those. Even with Delphi 12 there is a need for "Rodrigo Ruz's VCL Style Utils" to refine some smudges of some components (one for all TSplitView). I think, as others have said in that thread, that the look and feel are greatly improved over the normal OS dependent look.

I add to this discussion (which talks about formats in INI files) that a problem similar to that of the date also exists in the writing and reading of float values (i.e. numbers with decimal points). It is necessary to use the TFormatSettings and set the correct values (which are those of the files and not of the language). The example is when you go to write a value in an environment set in Italian (where the "comma" is the decimal separation sign) and perhaps then read it in an environment set in English (where instead it is the "dot "). I override ReadFloat and WriteFloat of TIniFile to correct that to always read and write the right values. Of course it is for compatibility and maintenance of the old programs, the new ones use a local database to store the data.

May be you must write a "little" interface between disk data and you record data. You can maintain your record data in memory without any changes, and when you read and write the data you can adjust in memory the reading. If you works with records, you can works writing and advances records, put the variables in private section (renaming them) and writing functions with the old names: current.field := V22.field TV22 = record private fV22_field: cardinal; function getV22_field: smallint; procedure setV22_field(Value: smallint); public property field: smallint read getV22_field write setV22_field; end; function TMyRecord.getV22_field: smallint; begin //You can do here what you want to adjust the operation Result := fV22_field; end; procedure TMyRecord.setV22_field(Value: smallint); begin //You can do here what you want to adjust the operation fV22_field := Value; end; Of course you must do this for every field you have declared that needed to be adjust.

May be those can Help (simple google search)? https://github.com/mattia72/vim-delphi https://github.com/Tanikai/vi-delphi

If NetWkstaTransportEnum belongs to APIs that use netbios, netbios itself may be disabled. Microsoft has begun to disable NETBIOS by default, still leaving the option to enable and use it. I read an article about this some time ago but I can't find it now.

Look this: https://en.delphipraxis.net/topic/10560-get-mac-address-using-indy/?do=findComment&comment=83985

Two weeks ago FastMM5 was updated: But Delphi 12 is a new release so be sure that all third parts components are updated and also that in the QP there are not such issue already posted.

... of course I'm aware .... It was a ironical replay to @David Heffernan ... Mantra "But it compiles to native code!" is a must for my business, may be only for me but that's enough. I have customers with dozens of machines (industrial lines) who are tired of hearing about frameworks that must be constantly updated, incompatibilities between functional blocks (effectively DLLs and third-party components) with each update, technology changes for "opportunities" of suppliers (for example instead of working with .Net 4.0 there is now .Net CORE x.x) which make many solutions adopted on old machines incompatible with the new ones. We are not talking about Java applications linked to a specific JRE which due to their "incorrect" development cannot be selected from the application itself (so if there are multiple JREs installed... nothing works). The customer who does not have "programming" as his core business but only the use of an IT product is not interested in the outline at all... he is only interested in not having any kind of problem in using it for the next few years. This is. How much the machine code is optimized is not a problem for my applications, or at least what optimization there is is sufficient. If I want optimized and performant code I use C or C++ (as already indicated)...

"priceless advantages" means that for me that solution has no price ... without that I will not be able to "sell" my product. Lol ... I didn't know that are toolchains that produce native code for Python, Java and C# ... may be I'm really old ... but I'm aware for C and C++ ( ) ...

I encountered similar problems in debugging, where some variables (mostly inline ones, but also some local ones) could not be inspected. But at normal runtime I have never encountered any problems. I use ExtractFilePath in a new project with Delphi 12 these days intensively with Threads processing millions of images and I haven't had any problems. N.B.: ... I only use English characters (plus spaces, underscores, ...) for directory and file names.