Leaderboard

I played around with this expert and added two things: - display with gutter: - two buttons to refresh or clear results: refresh can be used, when typing something on editor itself that modifies the result positions. If you like it, feel free to add it to repository. Please note: all modifications were only tested on Delphi XE11, but they should run on earlier versions too. As I'm not familiar with GX development: I have simply assigned two icons from GX Icon folder to speedbutton glyph, which probably is not the common way for GX. So you might change this to better fit the GX universe. Attached is a patch file with my changes: InstantGrepWithGutter.patch

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

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

SysInternals Process Explorer can show the path and version resource of each loaded DLL in a process.

I am not aware of any software that I use that refrains from releasing new versions until the current release version is bug free. Perhaps there are exceptions, but that is just not how software development generally works. To be clear, I don't think it's unreasonable to want Embarcadero to fix bugs, I do too. But complaining about Delphi 12 coming just because Delphi 11.3 isn't bug-free is not reasonable or useful, IMO. For what it's worth, I use Delphi 11.3 all day long. It is the most stable Delphi has been for me in years. I do not regularly experience the kinds of problems you describe, and pretty much every time I have, I could track it down to a component package. I do often have to restart Delphi when I am rebuilding packages or changing packages. It's an area that could use some work but I also understand what is happening -- I have a lot of components installed and any bugs in those components can affect the whole IDE. My biggest complaints have to do with invalid syntax highlighting between ifdefs that the IDE isn't interpreting correctly although compiler works properly. And, CTRL+Clicking doesn't always locate a symbol definition when CTRL+G does, and vice-versa (so I can't just use one or the other, I am often forced to try both methods). But, right now, I am able to use the IDE all day long with relatively minimal frustrations. I'm not trying to disregard the issues you are having, but being realistic means understanding that if Delphi is going to get bug fixes, they have to be able to get revenue, which means sustaining subscriptions, which means shipping new features. As I said before, it is what it is.

Another approach would be to declare a TMessage descendant that the frame (and probably also any form) subscribes to during creation and unsubscribes from on destruction. Then you can broadcast this message when the language changes. uses System.Messaging; type TLanguageMessage = class(TMessage<string>); ... procedure TMyFrame.HandleLanguageMessage(const Sender: TObject; const M: TMessage); begin var msg := M as TLanguageMessage; SwitchToLanguage(M.Value); end; ... TMyFrame.Create FLanguageMessageID := TMessageManager.DefaultManager.SubscribeToMessage(TLanguageMessage, HandleLanguageMessage); ... TMyFrame.Destroy TMessageManager.DefaultManager.Unsubscribe(TLanguageMessage, FLanguageMessageID, True); ... NotifyLanguage TMessageManager.DefaultManager.SendMessage(nil, TLanguageMessage.Create('DE'));

My take on this is that you want to start making changes in your Delphi 7 code base that don't change the meaning of the program there, but mean that it will compile and work as expected in both ANSI and Unicode Delphi. In an ideal world you'd be able to do all that work preparing for the switch and reach a point where you can compile with both ANSI and Unicode Delphi, and the program works the same. Then you can cut the chord to Delphi 7 and commit to Unicode Delphi. Then you do the second piece of work which is to get the code working on 64 bit.

It depends on the actual sources. I have had projects that just needed a compile with the new version and target, while others lasted several months.