DelphiUdIT

HOW TO DO IT ? Insert this in the code: {$WARN BOUNDS_ERROR ERROR} Refer to: https://docwiki.embarcadero.com/RADStudio/Athens/en/Warning_messages_(Delphi) P.S.: by now this will be a standard directive in all my code

LOOOL, every time is an improvement ...

Uhmm, I think there are good... actually very good reasons why "errors" are generated (AND SHOULD BE) in "Integer and Unsigned Integer" cases and the like. The first and most trivial case is the comparison operation. Comparing (or assigning) integers and unsigned integers is a huge mistake (i.e. it happens in the example from which the topic was generated). I think this is enough to define that there cannot be operations with "automatic" type conversion in these cases. Forcing the operation (therefore through typecasting) is the path that should be followed: the programmer knows what he is doing and solves the problem by forcing the operation. Already the definition of "-1" could create some "stomach ache" (it is an Italian way of saying that it creates "discomfort"). Those who programmed in assembler certainly remember the old Intel CWD-type instructions... A runtime, in Delphi 12 an Error was generated at the second instruction (like you told, "more dangerous") only in Debug mode ('Range check error'), but during compilation many warnings are generated regarding its use. Maybe the Warnings are not enough, they should be switched to error... HandleInteger(B); It is for this reason that it should not be allowed to carry out automatic conversions, already at the compiler level. I use and love Delphi, among other things, because when you write code and compile it you have a good certainty (I said "good" not "sure") that the code will run error-free, at least for basic errors.

May be this is the cause:

Mat be you are using it with UINT32 parameter or something like that ?

May be there is a little trick to discover something: - open a "dproj" file and search for a "<DCC_UsePackage>" section, inside that should be "Intraweb_xx_D10_3" for example, this means that its developed with Delphi 10.3. Look that and you'll find a version ... - from Delphi XE7 you'll find "emsclientfiredac", inside the same section, if the version used is a Enterprise (or Architect) Version. These informations are not official and not sure, but may be a starting point.

Sorry, but I don't understand ... you have found the issue (in the UTC_Time_Decode function) and change the code to read 4 digit (that you select based on the length of 12 or 14 characters). So how can we help you ?

Pay attention to the antivirus, it may block the ZIP because it thinks it has been compromised.

This has happened to me in the past when in the source files (even those called in the Uses) there were strange characters or the line ending was not CRLF. I also saw some anomalies when the declared class name and the implemented one (in the methods) differed due to the character case. But I never delved into how much it all impacted the code. Since that time I have made sure of both CRLF characters, especially from what is copied / pasted from sources external to the IDE by first copying into a text editor and forcing the thing and then into the IDE.

To me all is working right, and the image that you send is the same for me. I don't know if patch 1 is needed to use the "new" getit (I use it with patch 1 installed and all works fine).

If you install the patch manually nothing will be displayed, if you install with GetIt you'll get the patch description in the About box. Bye

It's a GetIt Helper But i don't know how to help you. If someone of the forum have some sight, otherwise you should reinstall Delphi 12

Why you have to reinstall Delphi12 ? Reinstall it means that you first must uninstall ALL (and delete directories and registry key) and after you can reinstall it. Waiting for new Web Installer, you can install only from ISO again and after that apply patch 1.

ISO installer, except for registration time, install all without access Internet, and should works. So should not make any difference between now and November (before outage and getit not working) The original ISO release MUST be downloaded from My.Embarcadero.com page.

You can share the form and the code a design time between the applications. But at runtime they are all isolated. You can exchange data between them via the methods mentioned in the previous posts, but also with a database where every application put their results ... you are able to process all these informations like you want. Bye

If components such as DBEdit, DBGrid or similar (dataware components) are present in the Form and these are active at RunTime, it may be that the delay is linked to the connection timeout with the DB engine.

I never use them, but may be some are "Konopka Controls" (aka Raize Components). You can download them from My.Embarcadero (or from getit when it will be available). Bye

I read that sometimes delete the .DST file (for example "Default layout.dst") will help (make a copy before .....) When the IDE start the file will be recreated again. I use this layout:

Sometimes, but years ago, I had the same problem. The executable is not show in the Task Manager or in Process Explorer, but it was running ... or better is locked in the shutdown state wait for something. Sometimes you can delete it from disk, but pressing F5 will see it reappear. Other times, as you reported, you can't erase it. At that time, not being able to understand what was happening, I inserted an "exitprocess" in the "destroy" event of the main Form and that solved the problem. Then subsequently starting to remove the "exitprocess" I no longer had any problems. But I can't tell you if it depended on the Delphi version or the operating system. However, if I remember correctly from "Process Explorer" you can do a search with the name of the executable and it should find it for you (use "Find Handle and DLL" from the menu). Bye

For me is working now, but like you told their services are not stable.

For me all the sites are working, except getit ... I don't think is a good idea to insert your credentials here, until they are official announced like partners of Idera.

You can read this: https://en.delphipraxis.net/topic/8569-indy-with-openssl-111-support-is-fine/?do=findComment&comment=72163 EDIT: The "299" repository was archived and it will not be upgraded anymore. This means that all updates from the official Indy repository will not be applied. Trying the route you indicated could be a good solution to temporarily implement compatibility between the official Indy distribution and OpenSSL 1.1.1. Let us know what's next. Further note: on the Indy github page if you go to the TAGS there is the official distribution supplied with Delphi 12 with all the packages too... the 290 package is still missing.... However, I think that it can easily be derived from the 280, not It seems to me that the components at design time have changed between Delphi 11 and Delphi 12.

Look at this: https://github.com/IndySockets/Indy/wiki Read <Updating Indy> on the right side. I do it more than one year ago and Indy is working also with OpenSSL 3.1.4 (for lot of functions, not for all). I did it with Delphi 11.x and 'cause actually problems with Embarcadero I have not tried with Delphi 12. Take care that this is not a good moment, is better to wait that Embarcadero restore all services. Bye