Tom F

Another vote here for David to get the time to update the plugin. I'm so accustomed to using his great Bookmark tool that it's really frustrating to have to wait. It would be nice if Emb actually staffed the RAD Studio team so that things like this (and so many others) didn't get delayed.

Edit: GetIt is now working again. In Windows 10, I updated from Sydney to Delphi 11 using the ISO. However, in the IDE, trying to access Tools > GetIt Package Manager results in: The Embarcadero GetIt server could not be reached... Error loading data from the server getit-olympus.embarcadero.com: Forbidden The Welcome screen's "New in GetIt" panel also reports "Error loading data." The GetIt Package Manager runs fine on the same machine in 10.4.23. I ran: GetItCmd.exe -c=useonline as an administrator and got "The command finished with success." But the problem remains. There is a discussion here (https://en.delphipraxis.net/topic/3909-delphi-104-getit-connection-issue/ on a similar problem, but it's for 10.4 and is 11 months old, so I'm hesitant about making any of the changes mentioned there. Any suggestions on fixing this?

I'm sure this has been discussed ad nauseum before, but I haven't been able to find with Google any info on this. I'm using VCL in Sydney with FireDac to SQLite. Is there a way to have a TDBGrid be updated live as I'm dragging the vertical scroll bar, rather than waiting until I release the mouse? I thought maybe Qry.FetchOptions.Mode := fmAll; would help. But it doesn't. I had hoped to find some useful info here, but didnt': https://docwiki.embarcadero.com/RADStudio/Sydney/en/Browsing_Tables_(FireDAC). Nor here: https://docwiki.embarcadero.com/Libraries/Sydney/en/FireDAC.Stan.Option.TFDFetchOptions.CursorKind. I could use a TStringGrid or other component here too, but StringGrids seem to have the same non-live update while vertical scrolling. I don't want to use a third-party component. Any suggestions? TIA

@Uwe Raabe Wow! Amazing! That works beautifully!!!! My grid no longer behaves like it was created in the last century. THANK YOU SO MUCH.

Yes. I had hoped that at least a StringGrid would live update (since it's not attached to a data source.) But, nope. They have the same problem.

Good point, Lars. Yes, it could imply potentially hundreds of queries. But, in my case, I have several thousand records so there's no reason they couldn't fit in RAM and be updated if the source table changes. No?

Good idea. It's hard to imagine it hasn't been asked for for literally decades, so I'm not confident of any action on EMB's part. But, yes, I'll file a feature request. Thanks for the suggestion.

Thus assuring that anyone who wants to create a modern UI has to rely on third-party tools. That's what I was afraid of.

If a user reports an exception like the one below, is there a way to track it down without having shipped an exe built with EurekaLog or MadExcept, etc. My release builds do not generate a .map file, but I can easily rebuild the release to generate one. But, I don't understand how I'd use the 00687017 address once I'd done that to find where in my code the exception occurred. How do I enable the Goto Address menu option in the IDE? Any opinions here on EurekaLog vs MadExcept for distributing with a Win 32 app to help with situations like this in the future?

Can you explain what you mean by that?

Hi, Stefan, But, if I shipped my app without debug info, and I want to find an address in THAT build, how do I get to a breakpoint?

Hi, Uwe, Thanks for your response. That's where I got lost. I shipped my app with no debugging info. If I want to trace down an address that's accurate in that version, I'd compile with the same flags as my shipped version, but this time generate a map file, right? That's no problem. But, then, how do I get to any debug windows (like the CPU window) when I start the app in the IDE with debugging, since there are no settable breakpoints.

What do you mean by a "detailed statement," Stano?

You're welcome. It took a lot of time to write. Good luck on your project. I'm headed back to coding. See the earlier post by @Stefan Glienke about your #3 being less likely to fail in the future if you change the enum definition.

Mike, You asked me what I meant by digging "too deeply." Suppose you want to drive from New York City to San Francisco. It's about a 43-hour drive. Suppose your friend says, "Oh, I can make your trip shorter. When you get to Chicago, there's a very long stoplight you'll probably have to sit at for two minutes waiting for it to turn green. But, to avoid the slowdown, I know a great detour. It'll save you about a minute. Turn left when you get to Main Street, and then turn right at the next street, go two blocks, and then turn right again and then turn at the next left. This will take you around the block, avoiding the stoplight delay, and then rejoin your original route to continue on your way to San Francisco." Would you take the detour? The detour is faster than staying on the route with the long stoplight. But is it enough faster for you to worry about? Is it enough faster to bother taking? Is it enough faster to risk getting lost on the streets of Chicago? Is it enough faster to spend hours discussing on forums? How much faster should the detour be before you're willing to take it? How much risk can the detour add before you think to yourself, "I'm not going to take that detour." ??? In your code, you have no idea how long the trip is. You have no idea where the bottleneck slowdowns are. So, you have no idea if the proposed speedup will be significant. And people here in the forum are telling you that your detour (new code) may be riskier (i.e. more difficult to maintain.) Suppose your enum code is currently consuming a total of .0050 seconds every time a user clicks a certain button. Suppose you spend hours writing several versions of alternate code. Suppose your new code speeds up enum strings so that they're now TWICE AS FAST, so that processing enums only takes .0025 seconds. Was it worth your time to work on this? What many of us have been saying to you here and elsewhere is that the revisions (detours) that you're suggesting to speed up your code are insignificant and may bring risk. You need to learn how to put your efforts where they will have the biggest impact on improving your code. The first rule is WRITE THE CLEANEST, MOST MAINTAINABLE CODE YOU CAN. Then MEASURE your application with a performance monitor/profiler to identify places where it's slow. A profiler will help you do this by showing you exactly where your code is spending its time. It's likely that the amount of time your current code is spending on enum strings is infinitesimal compared to everything else your code is doing. So even if you speed up the enum code, the speedup is likely to have no impact on your users.

If you're refactoring for maintainability, then I suggest you don't waste your time digging too deeply into speed benchmarks and certainly not into the assembly language.

If you haven't benchmarked your application to see how much time this code consumes in the context of your application, you have no way of knowing what "significantly slower" means. I'd bet that you could slow down this function by a factor of 1000 and it would NOT noticeably impact your users' experience or computer resources. You're wasting your time. Why have you chosen to waste your time working on something that doesn't matter? As Glienke says, "Version3 is the best because it's maintainable and gives compile error if anyone decides to add a new value..."

Hi, Mike, No, this wasn't posted in the wrong thread. You said you were refactoring. There are two reasons to refactor code that I'm aware of: 1. Make it easier to maintain. 2. Significantly improve the speed of the software. To answer your question about which approach is better, we need to know of the above two are you doing? Since you've provided speed benchmarks, I assume that it's #2 -- you're trying to significantly speed up your software. I suspect that you are prematurely optimizing your code for speed before you know where the bottlenecks are. Have you used a profiler to determine where to best focus on speeding up your application? Even if you made this code infinitely fast, would you or your users be able to notice the difference? If your answer is "yes" – then we'd love to hear about this novel application. If your answer is "no" – then you're wasting your time.

How did you decide that this was code that you wanted to optimize? Have you profiled your application to see if this conversion is a significant bottleneck? These aren't rhetorical questions. I am genuinely interested in your answers. I hope you'll answer them here in a posting.

I'm looking to capture usage data. AppAnalytics was formerly available, including access to a server and reports. Emb still makes the code available it seems, including server code. But apparently there is not subscription access to a server for actually collecting data, unless we provide the server. I suspect that's way over my technical skills. So, has anyone have a suggestion on similar usage metering similar tool with a Delph app (Sydney)? TIA

I'm about to update to 10.4, having waited while EMB QA once again failed and we had to wait for them to remove bugs that should never have shipped. (Yes, I'm bitter about that, but that's a discussion to have another day.) Rather than continuing to suffer from EBM releases that are defective, I'm going to for the first time develop on VMWare VM. This will of course allow me to easily roll back to a previous release. One reason I haven't done this in the past is that I have never been clear about how much I should install in the VM itself, and how much should remain on my host machine. If I put my source code (which is regularly backed up from the host to a repository) in the VM, then it seems that so many of my other tools also have to be in the VM, like my grep tools, and other utilities (like Beyond Compare, CI tools), etc. I don't know the best place to draw the line on what goes where. Perhaps I should leave my source on the host drive, accessing it from the VM? This is less than ideal, because my archives would have two pieces (the VM, and the source on C:). And it also means that I'll have to remove all of the hardwired C:\ paths in my scripts and other tools. To people using VMs for product development: how much do you install in your VM? Does your VM access your host drive for anything? Any suggestions?

Your workaround above did not work for me. The only work-around I've found is to restart the IDE, select "None" for Code insight manager , then open the .pas file that was causing the crash. If I want, I can then re-enable LSP and it works fine in all files, including the one that was causing difficulties. The above doesn't always work for me but usually playing around with the Code Insight manager setting for a few times after a few crashes finally lets me load the file.

Pat, loading an extra IDE doesn't solve this problem, which isn't a "disappearing act." The application bde.exe actually terminates and Windows generates a crash report. Dave, I've got 8 of 16 gigs of memory free, so a shortage of memory is not the problem. Thanks for the good suggestion though. I hadn't thought of that... I've discovered through a lot of trial and error that when I encounter a unit that when opening a file crashes the IDE, if I restart the IDE and toggle CodeInsight between LSP, Classic, and None, (sometimes a few times) I can usually load the problem .pas file. I haven't found any predictable sequence of toggling. Sometimes (but not always) I can load the .pas file into the IDE without a crash, regardless of whether CodeInsight is configured to LSP, classic, or None... 😞 This toggling procedure is not a fix, of course. It may simply be that there's some uninitialized memory that the above workaround leaves in a better state. The toggling procedure isn't even a reliable workaround since it apparently has to be done after the crash. All of this means I'm probably going to leave all my large forms and frames open in the IDE and not shut down the IDE for weeks at a time in an effort to avoid the problem. But at least I'm not stopped dead in my tracks. I also had a graceful crash in the IDE occur while I was testing this. I grabbed the call stack and other recommended files (like the DxDiag output) and appended them to the original RSP https://quality.embarcadero.com/browse/RSP-34109.

A quick note to anyone looking at this thread. You probably would have figured this out on your own, but, looking at the Task Manager, it appears that when you re-select the LSP on the Options screen, you have to close and re-open any open project for the IDE to re-launch the LSP.

Darn, I was afraid that's where you were referring to. Unfortunately, I don't have any of the git entries filled in. 😞 So that's not where my problem is headed. What bothers me is that the crash is so hard. There's no message or anything. The IDE just disappears. Most programs pop up a message box with exception errors. The Windows error log shows the crash, so perhaps somehow the IDE or my machine are now configured in some way to not show any crash messages. Or perhaps this particular crash is just too deep. Although the problem has been intermittent, at the current time I have a reliable way to make it crash. i.e. There is one particular.pas file that crashes every time I try to load it. I am making a VM backup of my development environment and noted in a comment in the RSP, hoping that EMB will ask for me to provide it.