DelphiUdIT

It is one-to-one color mapping, means the every 8 DI+ BitAlarm are assigned the a Color0-Color7 + ColorA(larm). Graphically, I don't know if the control provides for the possibility of displaying all 9 states at the same time.

May be you means: P.S.: .... I didn't see the Remy post ... void __fastcall TForm1::Button1Click(TObject *Sender) { int numbers[3]; int t; Edit1->Text = ""; //Clear the Edit1 for(t = 0; t < 3; t++) numbers[t] = t; for(t = 0; t < 3; t++) Edit1->Text = Edit1 -> Text + IntToStr(numbers[t]) + " "; //The new text is "added" to the Edit1 content (the number must be transformed into text) }

Hallo, for those unaware, Embarcadero has posted updates to the new offline Help for Alexandria 11.3. This is the download link for the files. http://docs.embarcadero.com/products/rad_studio/ Bye

It works for me too.

You can use "grep" command line application (at command prompt). I use that to find reference of something in source directory of Rad Studio. I.e.: serching the word database in all PAS files in every subdirectories. You can repeat with *.DFM to search such reference in the object property.

I have never used Omron components (although I have been a direct customer of Omron for more than twenty years) because I developed my own series of components, starting from the communication protocols. This is because I had to develop applications that already used fiber optics before the 90s and Omron didn't have high-performance components at that time (let's just say it didn't have components...). However, I managed to find in my archives the COMPOLET 2.0 (year 2003) and they are for WINNT3 SP3 or Higher. If you want I can send to you a private message with link (on my server) to download them. If you are able to install these, with Delphi 5 you can extract the TLBs. I don't know if something else (e.g. FINS GW) is needed to install them (I hope not). Bye

I don't think you'll fix that easily, those components were part of communication packages that no longer exist. They were imported from ActiveX (Omron never supplied wrappers in Delphi, I'm going by memory) registered either as integrated communication packages or separate components. The CX_ServerLite and CX_Compolet components are currently available but they absolutely do not support the WINNT environment. If you don't have the components installed in your VM or you don't have the Type Libraries or ActiveX wrappers (*_TLB.pas), you can't do anything with Delphi. It is probable that to install the components in your WM, even if you could find them, you would need the SYSMAC_BOARD drivers (I think you are referring to a C200PC-ISA1 PLC, it's the only one I remember ever seeing). If you have the original PC available you could theoretically recreate all the wrappers from the installed ActiveX. Not an easy job but doable. But first check if you have *_TLB.PAS files somewhere, like in the IMPORTS sub-directory of DELPHI5 (in the original source, from the customer, ....): If "Yes" you can copy in your WM, register them and load all the FORMS. Bye P.S.: may be also if you have the *_TLB.pas files registered, some parts of the Form will not be design correctly if you don't have the components installed (normally they are DLL or EXE or OCX in that time).

I don't know nothing about WinSat, but what you knew in the past is different from what it is now. [Win32_WinSAT may be altered or unavailable for releases after Windows 8.1.] <------------------------------------------- THIS DOESN'T EXISTS ANYMORE Look at new TLB that i post and this piece of source ... i hope this can help you. WINSATLib_TLB.pas

Also "inherited" should be removed, as the method is not a "redeclaration" of an existing method.

From the IDE: Bye

Is not a normal DLL is a COM object. This is a type library definition (you can make your own with IDE). Bye WINSATLib_TLB.pas

Win32_WinSAT class Article 12/12/2020 2 minutes to read [Win32_WinSAT may be altered or unavailable for releases after Windows 8.1.] <-------------------------------------------

I never use a DOCKER, I always used normally operating surface and the only things that you need are the two .so libraries x Linux. In one of my original projects, I used the standard Indy release with the Delphi, the libraries that I had are 1.0.2u (Linux 64 bit) but the names exposed are: libcrypto.so.1.0.0 libssl.so.1.0.0 I don't remember why (it happened 2 years ago) but i had also in the same directory the binary copy of the libraries with these names (and that i think was for Indy link); libcrypto.so libssl.so If you have your Linux app, these libraries and optionally the .pem certificates you server must works. You don't need other things. Bye

May be you mean: var tempointer: Pointer; tempointer := Combobox1.Items.Objects[Combobox1.ItemIndex]; Combobox1.ItemIndex := Integer(tempointer^); But even if this is correct, the starting point is incorrect: PAY ATTENTION: SqlQuery1 I think dynamically allocates Fields[1] and therefore your POINTER will be invalid after a new QUERY is executed. The pointer used with the AddObjects function should be permanent and "last" for the entire existence of the program (until you know what you are doing ) Bye

This might be "OT", but just one piece of advice I want to give to @shineworld In general, expressly if commands are given to automations, the software (see for example SCADA) requires an authorization level. These levels are normally kept inside a server-side db and have nothing to do with PC users, Windows users, Linux users, etc ... So in the end, in your client communication you could simply enter a name / password that the server program will validate among those in the archive to validate the request. You wouldn't need anything on the client side other than this data pair. If a command is executed, the operator enters this pair by hand and the client sends it to the server together with the command, if instead a status request is executed it could also be that the client sends a hardcoded name / password by default. Of course the server must validate the couple of auth to actuate the request. The communication between client and server (and vice versa) remember that it is always encrypted if you use TLS. Bye

These not resolve other question about i wrote: where and how you maintain the couple of accounts right (Username / Password) to impersonate the user of the "cert store" ? ..... like I told another level of crypto .... This is a non sense for a simple TCP / IP communications: client with a "hidden" user that should have a "certificate" in personal windows store (with private key and a password for that) and a crypto for username / password of hidden user ... I don't think a sysadmin of any company would agree to such a choice: i asked to 3 company one little, two big, of course in private and unofficial conversation and they negate these approach. All three would impose the use of the supplied USB stick on all their staff, or in second hand the registration of the software (this last would be my preferred solution). This choice depends on whether the application is autonomous (for example the customer launches it and then it must "run" as long as the customer is logged in) or if it is launched in autorun when the customer logs in and runs without particular interactions with the 'user. But we are in a free world and everyone is free to make their own choices. The important thing is to continue to offer solutions. @shineworld talks about TCP / IP communications with is "proprietary protocol" and not about HTTP. Using Http is another question. Bye

It would be a good idea but there are two problems: 1) Create a different user (different from an administrator user and from the user where the application runs) on all the machines where the application runs ... I see it as a real complication for management and maintenance. And in any case the credentials to impersonate the user must be "hard coded" in the program or in an external file, therefore local encryption ... at this point it is better to locally encrypt the direct access credentials to the server or directly the certificate files. .. but it doesn't make much sense, you just lengthen the chain and don't solve the underlying problem; 2) Indy does not support access to the Windows Cert Store ... at least as far as I know, until the keys are exportable .... Bye

A reflection on the discussion and on the concepts of "trusted". If by trusted it is meant that the connection between the client and the server is practically secure and that the client knows who the server is, then the concept of trusted is verified with the use of a server-side certificate (possibly issued by a recognized certifier and not by a self-signed certificate) and an encrypted connection via TLS, and that's what the example I posted does. But if we expand the concept of trusted, as I think @shineworld intends, then it is more complex to apply it. The "expanded" concept is that the connecting client is known and certified as if it were a server. A standard certificate (similar to that of the server) on the client side is not applicable because the files are exposed, especially the private key even if protected by a password, and anyone who can access the station could "copy" it. A solution would be a "hardware" certificate (as in a USB token), but it is not an economic solution and there is a fairly important management for the tokens: it must be said that many private companies and all public companies have by now equipped employees with a USB token or similar (token like credit card, etc ....). Other easily applicable solutions are then: apply the concept of "registration": at the very first connection (client installation) the client sends runtime data to the server (date and time of installation, processor UUID, etc ....) which the server registers (with its own coding ) and will use to test future connections. The client will send this data at each new connection and the server will refuse the connection if they are not included in the list of already registered clients. OBVIOUSLY THESE DATA MUST NOT BE DISCLOSED, IE MUST NOT PUBLICLY KNOW IF AND WHAT THE CLIENT SENDS TO THE SERVER (otherwise it is enough for a fake client to replicate the data of a real client to replace itself). apply the classic concept of username / password, but it makes sense if the entry is done by operator, if it has to be automated it means that username and password must be stored locally .... so other local encryption, .... etc ... . Bye

I post a simple TCP sample using SLL (TLSv1_2). It's only a little start point, but may help you. Inside there are the OpenSSL Win64 dll 1.0.2u and one certificate self signed valid for one year (localohst, 127.0.0.1). There is also a DHParam file used for DH "chiper" protocol, not necessary and not used. From there you can improve security, authentication, etc .... Bye TCPS Demo.zip

With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs.

In the past surely not. I always used "mine" libraries. Of course there are issues with versions (1.0.x, 1.1.x, 3.0.x), so it's best to distribute your own anyway. Bye

Really interesting, knowing if a file is already in use by another application via an api instead of trying to open it and manage the error (without knowing "who" is blocking it anyway) is very useful in some scenarios. Bye

With respect to your request, and speaking of databases, I've honestly never heard the concepts of UNDO / REDO but the concepts of COMMIT / ROLLBACK. All databases support the concepts of TRANSACTION / COMMIT / ROLLBACK. The main difference between theoretical and practical use is defined by both the DB used and the component used to manage the database (e.g. FIREDAC, ZEOS, ADO)..... I've never used Interbase, but I've used FireBird even if not "heavily" and the TRANSACTION support from the DB is complete and it's multi-user with the possibility of setting the LOCK resolution mode. Now I don't remeber if FIREDAC supports transactions at DB level (therefore multiuser, auto lock, ....) or at connection level (1 transaction for each connection, therefore not native multiuser). ZEOS only supports connection-level transactions, therefore 1 ACTIVE TRANSACTION for each connection, no concurrent multi-user. EDIT: my fault, there is no concurrent MULTI TRANSACTION with same client side application. Means that only one sql editing instruction (for example) = one transaction may be in use concurrently in that client side app. MULTIUSER from different client is always possible and even with multiple database connections, multiple concurrent transactions can be made. In any case the solution can be using only the transactions, and this is expressly true if there is multiuser. The resolution of inconsistencies, locks and all other problems is very complex and cannot be solved "manually" at the application code level. This is the page for the FireBird documentation, where the mechanisms of LOCK, TRANSACTION, COMMIT / ROLLBACK are explained very well. Bye P.S.: of course, a careful design of a database is always necessary, regardless of the use of TRANSACTIONs.

I saw, but the main loop should be ... A LOOP .... and in a console app there aren't so many variants .... It simply instantiates all objects at runtime (the graphical application you see instantiates everything at runtime, it's just for convenience and debugging that there is a graphical window). In the main loop you can do: var EndLife: boolean; begin EndLife := false; // Runtime object creation // End {$IFDEF POSIX} //is used to intercept the CTRL-C, in order to terminate the program correctly sigIntHandler._u.sa_sigaction := @my_handler_ctrl_c; sigemptyset(sigIntHandler.sa_mask); sigIntHandler.sa_flags := SA_SIGINFO; sigaction(SIGINT, @sigIntHandler, 0); {$ENDIF} while not EndLife do begin //In here you can put for example a WAITFOR with 100ms timeout, you can update a log file, send an I'M ALIVE, capture a variable to stop / start the web server ......... end; // Runtime object destruction // End end; //Capture CTRL-C, CTRL-BREAK, LOGOFF, SHUTDOWN, CLOSE ... events. I DIDN'T TEST THEM !!! {$IFDEF POSIX} procedure my_handler_ctrl_c(segnale: integer; segnale_info: Psiginfo_t; context: Pucontext_t); begin //writeln('Caught signal ', segnale); EndLife := True; _exit(1); end; {$ENDIF} These are simply an advise, i don't test it but i think may be a start point. Bye

May be yes, there are some significant differences .... first of all the use of pointers directly ...... these means that the errors are no so clear. If you use the normal array definition you get "Range check Error" instead of "Segmentation error"... isn't this enough? And in general, unless there are speed or interfacing problems with particular APIs, why use direct memory management in PASCAL? In all my life as a programmer I have no memory of having directly used GetMem in PASCAL, I have never felt the need (but I have programmed parts of code in assembler). If I have to interface with "something" that can't be handled in Pascal, I create a DLL in "C" and work them with the "C" style. But of course everyone is free to act as they wish, fortunately. Mine was advice. Bye