Mark Williams

@Sherlock Error Insight (didn't know it was called that) seems to be working fine for me since at least 10.2. It is really useful. Compiling and re-compiling to detect errors is just so painful.

Thanks.

Do I really need to make that choice? As the inline vars compile ok they shouldn't be underlined as code errors. So I was wondering if there is an option I needed to configure in the IDE to prevent this issue or whether it is a bug in the new IDE. If it is not a configuration option then I assume it must be a bug. So I would rather not make the choice. I would rather get an answer and if it is a bug I will report it and hope it gets fixed.

I quite like the underlining of errors. Really handy to see at a glance where your errors are without having to recompile for each one.

I thought I'd give the new inline variables a try in 10.3.1. When I enter eg "Var b:=true" it is underlined in squiggly red to indicate a code error (as are chunks of the subsequent code) but it compiles fine. I would like to use this new feature, but this is going to get me confused as to where actual errors do actually lie. Is this a bug or do I need to configure something in the IDE to stop this happening?

Yes. Sorry. Of course I meant exception. Thanks for the info. Will try that out and see if it is the problem.

Occasionally, when I am debugging a particular app, if there is a bug in a section of code, the debugger opens one of my units (always the same one and which wasn't previously open or changed) and reports a bug in a specific line in that unit. The report is wrong there is no bug. If I comment out the supposedly offending line in this unit and recompile I am taken to the correct bug. After I correct that, I can then go back to the incorrectly identified line uncomment and recompile successfully. Does anyone know why I am seeing this behaviour? I am using 10.3.1, but the issue was present at least as far back as 10.2

I have just discovered a component on the Windows 10 tab called TCardPanel. Seems very similar to a page control, but without the tabs. Maybe of some use.

I already handle it in a separate thread so that's all set to go. I use a separate thread also to check for any new records/changes etc. I'll test the encryption side. I have the feeling that the locally stored database will be 10s of MBs for a database with around 10,000 records. My experience of strong encryption for files of that magnitude is that it is slow. There's also the issue of where to store the encryption key. Hard-coded within the app is not a good idea. I could store it on the server and retrieve it on start up, but then the key is something which should probably be regularly changed for security reasons, which would then render the local file inaccessible. I suppose you just load it all over again from the server.

OK. Food for thought. TFDQuery has saveToStream abilities. So could be saved to a local file. Encrypting and decrypting such a hefty file would probably take a while, but probably better than the hit on the server. Certainly another option.

Thanks for the info. I gave up on byteA in the end. The data is an array of numbers. I now save it to csv and in a text field and then restore it to an array when needed. There does not seem to be any appreciable loss of speed. Would have certainly looked at ftStream otherwise.

Thanks for the input. I'm not sure if you mean to cache date locally as in save them to a file on the local machine and load from there on start up. I don't think that's what your saying, but if so it would be something I would be keen to avoid. I would think it would be the same for medical apps which doubtless process highly sensitive data. I only download the data once by way of a query on start up, which then remains static (ie it doesn't refresh). So it's effectively cached locally from that point. I then periodically run a separate query to check for new/modified records and, if it finds any, it updates the main query. That's fine over fast internet or local connection with 30000 or so records and it's great to have everything stored locally as you say. On a slow connection it can considerably slow down start up and that's why I am thinking of having the ability to load incrementally only what's needed where there is a slow connection or a monster number of records. However, although downloading in chunks, I am not intending to jettison any data downloaded locally once the user scrolls away. It will be retained locally in case the user returns to the same location in the tree. Effectively, I'm trying to do something similar to what dbGrid does in OnDemand mode save that if you Ctrl+END it loads the entire table, which I am looking to avoid. I should probably delve into the DbGrids unit and see what it reveals.

Thanks. Will do.

Ok. Noted, but not really my issue. However, for some reason the function is now working as expected in 64 bit and I have no idea why. Thanks anyway.

Thanks for posting all that. In terms of speed of loading and size of returned query etc I know there's a lot of sense in losing all the joins and displaying just the master data with some sort of panel display for the servant data which would update as you highlight each document. The problem with that is it necessitates stopping on each individual document to see what is happening with it, which could in itself become a major issue in terms of speed of scrolling through the tree ie having to arrow down instead of paging through it. I obviously need to give this a lot more thought, but thanks for food for that thought!