Leaderboard

Nonsense. Windows developers have been able to create professionally looking applications that for decades without the aid of layout controls. The main reason for amateurish looking applications is amateurish developers. The DevExpress layout control is tightly coupled to the rest of their library but even if it had been possible to separate it from the rest then it would be a terrible idea. Embarcadero does not have the resources or expertise to maintain and evolve something as complex as TdxLayoutControl. Just look at the state of the 3rd party libraries they already have incorporated into Delphi. I wouldn't mind a rudimentary layout control as a part of the VCL but if they can't even get something as simple as TGridPanel to work properly then I think it's better they not even try.

it will also be enough if QP is operational by the time D13 arrives

Update on the use of the TLS1_3 protocol in Indy (NOT OFFICIAL FROM Indy Team). This is an indication coming from the undersigned, who has carried out exactly what is described and verified that there are no problems either with the IDE or with the existing projects by recompiling and executing them. Conditions: - Rad Studio Athens 12.0 patch 1 (or Delphi); - Dowloaded Last GitHub repository Indy source: https://github.com/IndySockets/Indy/archive/refs/tags/Indy-10.6.3.zip - Donwloaded PR299 (aka NewOpenSSL_PR x OpenSSL 1.1.1): https://github.com/mezen/Indy/archive/refs/heads/NewOpenSSL_PR.zip Now you need to uninstall Indy from Rad Studio IDE, components and binaries included. YOU DO NOT NEED TO DELETE THE ORIGINAL INDY SOURCES. This is the official link explaining how update Indy: https://github.com/IndySockets/Indy/wiki/Updating-Indy ATTENTION: Do not use THE AUTOMATIC PROCEDURE in the instructions indicated in the previous link. It deletes files that do not belong to the Indy environment. You have to do what is indicated by hand, but when you get to the REMOVE THE FILES procedure, stop!!!! Instead, perform these steps: 1) Using Windows Explorer, go to the RAD STUDIO installation BIN directory (normally "C:\Program Files (x86)\Embarcadero\Studio\23.0\bin") and delete the following files: Then go to the BIN64 directory and delete the following files: Now you need to go to the LIB directory and list all the ID* files of the subdirectories (use the pane at the top right of the explorer to search). I recommend listing the files by NAME. The list includes a series of files (more than 10000) that will need to be deleted, BUT FROM THIS LIST YOU MUST UNSELECT (i.e. THE FILES SHOULD NOT BE DELETED) the following files: - all files starting with "FMX", should be 16; - all files starting with "Vcl", should be 8; - all files starting with "play", should be 4; - the "idoc.dcu" files should be 4; - the "idispids.dcu" files should be 4; The procedure indicated in the link (Update Indy) would have deleted these last 8 files. Now that you have deleted the files you will need to open the IDE. Errors will be generated: - package "dclemsedge290.bpl" could not be loaded, ignore and select not to reload again. - the "livepreview290.bpl" package, ignore and select not to reload again. Other packages may give errors, this depends on the fact that you have components registered in the IDE and that use Indy. You can ignore them and allow them to be reloaded the next time you restart the IDE. If you want to do a clean job, you should go to TOOL/OPTIONS/LANGUAGE/DELPHI/LIBRARY and from the "Browsing Path" item you will have to eliminate the Indy references (Core, System and Protocol) IN ALL PRESENT PLATFORMS. Now Indy is no longer present in Delphi. If you followed my initial instructions you should have downloaded the two zip files indicated. Unzip the first one (Indy-10.6.3.zip) into a directory. This directory will be the one containing Indy and will be used for all your applications. Now from the second ZIP file (NewOpenSSL_PR.zip) EXTRACT ONLY the OPENSSL directory found in "Indy/Lib/Protocols" and add it to the directory you created in the previous step, always under Lib/Protocols (so at the end there will be a directory plus, Lib/Protocols/OpenSSL). You will now have Indy with TLS1_3 enabled and with usable OpenSSL 1.1.1 (and also partially OpenSSL 3.1.x). Continue with the "Build and Install" paragraph of the link indicated initially. After finishing, you need to add two paths to Delphi's LIBRARY PATH to follow the ones you entered as in the instructions: "Lib\Protocols\OpenSSL" "Lib\Protocols\OpenSSL\Dynamic" You will now need to recompile (and reinstall) all of your IDE components that use Indy and your projects. For now the TLS1_3 can only be configured in code (therefore in RUNTIME), not in DesignTime as the IDE components have not been updated. All your projects however will remain perfectly functional and will use the old TLS1_2 standard and the old OPENSSL 1.0.2 DLLs until you modify the source to include the new standard. It's late and I'm going to eat now... UPDATE A note for those who use Indy to develop 64 bit or mixed 32 bit and 64 bit (even if you already know this): after having compiled and installed the Indy components (therefore 32 bit), delete the dcu files from the directories (where you unzipped Indy). You can safely delete ALL *.dcu files. If you leave them, when you go to compile your 64 bit project it will give you an error because the "dcu" are 32 bit. By deleting the dcu, you will force the recompilation (in your project) of the Indy libraries. Also remember that in the options of your project a valid path is indicated in the "Unit output directory", this will allow the compiler to generate all the dcu of the project within that directory.

Yes, two or four (for symbols behind BMP).

Your life will be much easier if you rely on Strings and Chars for text manipulation, not bytes. Convert to bytes when your text manipulation is done, not before that.

Unicode (UTF16) symbol size is at least 2 bytes, so after deleting 1 byte string became incorrect.

I am not familiar with Moodle, but I'd probably just roll my own. Take an Indy Http server, handle GET, PUT, POST requests, done. You're in full control. I never had the need for any of these 3rd party frameworks (I'm sure they're great, though).

Well, there are many ways to approach such a project. Using 20 images and 20 buttons may look appropriate at first glance but you have already identified the problem of code duplication and it is not the only one. Even getting the layout riight may be more work than you think. If you have a number of identical objects think array, and for visual stuff think grid. If your target platform is Windows and you intend to use the VCL instead of the FMX framework I would use a TDrawGrid as the main UI. For the start and exit buttons use TButtons hosted on a TPanel aligned alBottom on the form. The TDrawgrid is placed above the panel and aligned alClient. With 20 images you probably want 4 rows of 5 images each, so set the rowcount and colcount to 4 and 5, respectively and the FixedColCount and FixedRowCount to 0. Add a handler for the grid's OnDrawCell event, that is where you place the code to draw button (for an image not uncovered yet) or image. Then you need a way to store the state (covered/uncovered) for each cell and an identifier for the image a cell is holding. To keep the info for a cell together the natural storage is a record, so add a type definition like this above the form class: type TGameCell = record ImageIndex: Integer; Uncovered: Boolean; end; The game state is then a 4x5 array of TGameCell: const CNumRows = 4; CNumCols = 5; type TGameState = array [0..CNumRows-1, 0..CNumCols-1] of TGameCell; Add a field to the protected section of the form class: FGameState: TGameState; Each element of the game state array corresponds to a cell in the drawgrid. OK so far. Now you need some storage for the images. The most appropriate is a TImageList, so drop one on the form, set its Height and Width to the size of the images you want to use and then load the images into the list. The index of a given image will be used to identify it in the TGameCell. I asume with 20 cells you will have 10 images. Set the defaultcolwidth and defaultrowheight properties of the grid to values a bit larger than the images, say 4 pixels more. That gives you spacing between the tiles you have to draw. OK so far. Add a handler to the form's OnCreate event. There you place the code to initialize the FGameState array. The Uncovered members of the TGameCell records will start out as false, so you only need to set the ImageIndex to specify which image to show in each cell, using the index from the imagelist. That is the basic setup. Now you have to figure out how to draw the cells to resemble the usual memory game card. The event handler for the grid's OnDrawCell event has the following parameter list: procedure (Sender: TObject; ACol, ARow: Longint; Rect: TRect; State: TGridDrawState) Sender is the grid, you will have to draw on its Canvas, so add a variable for that to the handler sceleton the IDE created for you: var LCanvas: TCanvas; begin LCanvas := (Sender as TDrawgrid).Canvas; ACol and ARow tell you which cell to draw and, conveniently, these directly correspond to the matching TGameCell indices in FGameState. If you leave the DefaultDrawing property of the grid at the default True the VCL will have already drawn the cell background, so you can concentrate on drawing the image or button. Which it is you determine by looking at FGameState[aRow, aCol].Uncovered. If true you use the imagelists Draw method, passing it the LCanvas and the Left and Top members of the Rect parameter, adding 2 for the spacing to both. To draw the button the simplest way would in fact be to add a suitable image to the imagelist as well and draw it the same way. An alternative would be the DrawFrameControl Windows API method, but that is much more complicated to use. OK, so the form will now show the grid when you run the project (at designtime the grid is empty). Now you need to detect clicks on the cells, so add a handler to the grid's OnMouseDown event. Its X and Y parameter tell you where the mouse went down inside the grid but not which cell that is. Fortunately the grid has a MouseToCell method, so call that to get the cell, look at the Uncovered member of the corresponding TGameCell. If true exit directly, if false set it to true and call the grid's Invalidate method to get it to redraw. This would also be the place from which you then evaluate the game state, i. e. see if this action has uncovered the mate to the last tile uncovered (if so stop the timer), has uncovered the first tile (if so remember the cell coordinates and start the timer), and so on. If the timer fires you would just set both cells to Unconvered:= false, stop the timer, and Invalidate the grid to redraw. OK enough loafing around! Now get to work

In the meantime, I have come up with a solution. I have debugged something in the library. I found out that if the protocol is set to "ipLocal", the port is not taken into account. You have to change the protocol to "ipTCPIP" and set the host to "localhost", then it works. Follow the final code FUNCTION TfrmMain.GetFirebirdServerInfo: boolean; VAR FDIBInfo: TFDIBInfo; AVersion: TIBInfo.TVersion; AConfig: TIBInfo.TConfig; BEGIN Result := False; IF (teFirebirdInstallPath.Text = '') AND (teFirebirdVersion.Text = '') THEN BEGIN FDIBInfo := TFDIBInfo.Create(Self); TRY FDPhysFBDriverLink.VendorLib := teVendorLibrary.Text; FDIBInfo.Protocol := ipTCPIP; FDIBInfo.DriverLink := FDPhysFBDriverLink; FDIBInfo.Host := 'localhost'; FDIBInfo.Port := spePort.Value; FDIBInfo.UserName := teUsername.Text; FDIBInfo.Password := tePassword.Text; FDIBInfo.GetVersion(AVersion); teFirebirdVersion.Text := AVersion.FServerStr; FDIBInfo.UserName := teUsername.Text; FDIBInfo.Password := tePassword.Text; FDIBInfo.GetConfig(AConfig); teFirebirdInstallPath.Text := AConfig.FServerPath; Result := True; FINALLY FDIBInfo.Free; END; END ELSE BEGIN Result := True; END; END;

Case on Strings. i.e. case myStringVariable of 'A': do something; 'Test': do something; etc end;

Bug fixes, bug fixes and after that: more bug fixes. Don't release until there are no more unresolved bug reports. Quit following hypes just for the hypes sake.