dummzeuch

I'm not saying it can't be done. Just more work than I was prepared to put into it. Some of the features seemed to be missing too. But that was several years ago (when PCAN Developer was still called CanAPI2 or something like this).

We are too using Peak Systems hardware, but not with the free PCAN-Basic API (I tried it, but it was too much hassle), but the paid for PCAN-Developer 4 API. We use several PCAN USB interfaces per PC and many devices.The Delphi examples aren't that great though and there was at least one serious bug in one of them (I don't remember the specifics but it took me a while to figure it out. I reported the problem, so maybe they have fixed it by now.)

Does that even compile? With a variable having the same name as its type? Regarding the actual question: That depends on the variable type. If it is something that can fit into a register, the variable might not even end up on the stack. But if it is something requiring additional code, e.g. reference counting, there might be a performance penalty on top of the space it needs on the stack and the code to read and write it. I for one care a lot more for readability than efficiency, with very few exceptions.

You can bet they will. They always did wherever that number was about to turn up anywhere.

None of these features have been implemented. Feel free to submit a feature request on sourcefoge (makt it one for each feature). Feature requests for the formatter should include two unit files: An input and the desired output. They both should compile. But don't hold your breath for an implementation. Hm, actually, I think removing that blank line should have worked. Maybe it's a bug.

Hm, I remember hearing about the "Find related" stuff at the Forentage, but unfortunately I forgot what it does (I'm not a C++ programmer either). Care to refresh my memory?

My guess would be that it is the welcome page that does this, so you could try to customise it removing all the stuff that gets content from the internet.

Thanks mostly to the work @Achim Kalwa put into the preparations I have now built an installer for GExperts 1.3.23 Alpha for Delphi 12. Note the word “Alpha” in the release name. Basically I installed Delphi 12, fixed some problems with the build scripts and compiled Achim’s new project. Then I added the Delphi 12 version to the installer script and built it. Oh yes, I also installed the DLL in Delphi 12 and started the IDE a few times. That’s about all the testing from my end that went into this alpha release. ... Read on in the blog post

I wrote about the Instant Grep expert before when I was looking for a name for it. Now it's nearly finished and I need testers for it. Simply get the GExperts sources, compile a new DLL and replace the original DLL with the new one. Instant Grep is in the menu (not sure yet whether it should be moved under the Grep submenu). You can assign a keyboard shortcut to it if you like. It opens a new (dockable) window which greps the current edtior file as you type a regular expression and gives you a list of matches. You can use the cursor keys (up/down/pageup/pagedown) to move to the lines it found, press Esc to go back to where you started, or Enter to activate the editor window. The Window reacts when you switch to a different editor tab by searching that new file (only Delphi 2007 and higher). Warning: I have been using the expert all day (in Delphi 10.2 and 2007) and found many bugs and annoyances, but I think I found and fixed most of them by now. But still: Installing a new GExperts DLL might make your IDE unstable and even crash it.

If you were seeing an access violation with a self compiled GExperts DLL and the latest code, you should update the sources to at least revsion #4079. I fixed a bug there that caused an AV.

I'm not quite sure what you mean here. The Delphi compiler automatically checks if the internal timestamp of a dcu file is older than the currentl source code of a unit and recompiles it, if necessary. But what exactly does hat have to do with GExperts?

"Jump List for Delphi 11" is the "jump list" for the Delph icon on the taskbar, that is the popup menu you get when you click on that icon with the right mouse button. That's a Windows feature.

Actually no. With the normal GPL You only have to give the sources to those who you give the binary. You don't need to release it to the general public if you don't release the binary to the general public. If you only use it internally, you can keep your code confidential. If you give the binaries to a 3rd party, you will have to give them the source code too. That 3rd party does not release it to the general public, it will only be available to them. But: They have the right to release it and you are not allowed to restrict this right. As you correctly pointed out, the GNU Affero GPL closes a perceived loop hole that is created by internal use for a publicly available service.

Look here: Computer\HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\22.0\Experts

"GNU AFFERO GENERAL PUBLIC LICENSE" According to the abstract this sounds a lot like GPL. But whatever the difference to the GPL might be. This: ... means I can't use it in any of my tools. I'm not going to change the license from MPL to anything GPL like. I was actually thinking about using this to add support for 64 bit executables to the PE Information Expert in GExperts.

I'm unable to find the license for this library. Is it just me, or isn't it stated in the description?

Yesterday, all of a sudden, one of my Delphi programs failed to connect to various WMS servers on the internet. I got the following error message: Error connecting with SSL. error 1409442E:SSL routine:ssl3_read_bytes:tlsv1 alert protocol version Since I was using a recent version of Indy, this should not happen, according to this thread on Delphi Praxis. It turned out that somehow a very old version of the openssl DLLs libeay32.dll and ssleay32.dll had gotten ... read on in the blog post

No, the program should have had these DLLs in its installation directory. And it usually has. Yes, it should. It didn't though. Now it does. The error occurred on my development computer with freshly checked out sources. Normally missing DLLs would have caused an error message which would have reminded me to copy them from a subfolder. Unfortunately there was no error message, just the SSL connection failed. Hm, thinking about it: Maybe the loading code should specify the full path for the DLLs. But that would mean I had to change the Indy sources. I'd rather not do that. Alternatively my program could load the DLLs before calling any Indy code.

993 is the default port for Imap over TLS, so this is probably meant as a feature. (Not that I would have expected this to happen.)

Delphi 11.3 is the 3rd update for Delphi 11 (as opposed to the 10.x versions where each point version was a new release), so there have been updates and each of them fixed some bugs (11.0 was so bad that I didn't even want to spend the time for a GExperts release until 11.1 came out.) I'm not disagreeing that there is a lot of room for improvements, though. I'm not using Delphi 11.3 for production because it isn't stable enough in my environment.

I just made some time for it. I have quite a bit of overtime to work off anyway. #revision 4072

Yes, I kind of knew this (but didn't think of it). But using the internal functions will also help diagnose installations on computers which cannot be accessed directly. A program can present the user with this information or it can be included in an error message or log file.

Thanks! I was about to add these two myself, the next time I find some free time. Having your patch will make that happen a lot faster. I still need some time for this anyway. You are correct. The right way is to use the image lists in Source\Framework\GX_SharedImages, or since Delphi 11, to assign these lists at runtime. See any of the dialogs that have a tool bar on how this is done.

Another option would be to have a procedure like this: procedure TButtons_SetEnabled(const _Buttons: array of TButton; _Value: Boolean); var btn: TButton; begin for btn in _Buttons do btn.Enabled := _Value; end; And call it like this: TButtons_SetEnabled([Button1, Button2, Button3], True); Not much of a typing saver, but not as repetitive. Edit: Just noticed that Uwe already suggested a similar approach.

Does that one also allow pre-filtering the filenames? e.g. If I only want to select from GX_*.pas files, or those matching *.dbf;*.dat ? I already had a similar function for filenames and directories without filtering using SHAutoComplete, but the filtering was important for me. (Short answer: I didn't know about this)