Fons N

Hi, Just upgraded to Delphi 11.3. Just wondering if you guys have the same problem as me regarding the LSP. To be clear, I had this problem also in earlier versions, but was hoping it would be fixed in 11.3. In a small application, this problem does not occur. But in a big application it does. The problem is as follows: If I type in the first few letters of a variable, use Ctrl+Space, the little window pops up displaying the possible variables and routines. Great. Even in the big application. For example: obja it will find (among others) ObjAdministration But... if I type this: if obja nothing. No popup window. I am now so accustomed to typing in first obja and then use Ctrl+Space, select the variable or routine I need, type the Home key twice and then type if. It's a workaround, better than typing in the whole variable or routine, but it is annoying. Do any of you have the same problem?

I found this website to be very helpful. https://www.physiologyweb.com/delphi_code_examples/microsoft_excel_automation_with_delphi.html

On the contrary, I would take a Delphi component over a DLL anytime. My point is, transym.com does not sell a Delphi component anymore (at least not with it's latest version, which is at version 5). https://transym.com/download/ If version 5 would be available as a Delphi component, than there would be Delphi samples. There are none. Version 4 has Delphi samples, but only for 32 bit. I downloaded them, but unless I am missing something, it is still not a Delphi component. Maybe version 3 is, but the website states that the latest update of these Delphi samples where updated in December 2011. That is a long time ago. I know code doesn't rust, but as it is clear there won't be any updates that specifically supports Delphi, I would think twice before using it. A shame, cause the price, it's unrestricted use and what it can do, would be a top choice if you need OCR - if only it would be an actual Delphi component.

As far as I can tell from looking at the website, this is not the case anymore for newer versions of TOCR (currently art version 5). Last version that unofficially supported Delphi was version 4 and even in version 4 is not a Delphi component (looking at the source code examples).

Delphi Pro 11.2 Sometimes, you accidently click on the wrong event, it's automatically created but also automatically deleted when building and/or saving the code. This is still the case. But if you put in some code, but afterwards you changed your mind and delete all code between begin and end, then in past versions is would also delete the (now) empty event. It no longer does this. Unfortunately. Can anyone conform this?

Sorry.

In a KeyDown event (VCL) I have the following code: procedure CodeExample.KeyDown(Sender: TObject; var Key: Word; Shift: TShiftState); begin if Key = 37 then begin Shift:= [ssShift]; Key:= 9; end; if Key = 39 then begin Shift:= []; Key:= 9; end; end; The code in the Key = 39 part works. The pressed key is now a tab. The code in the Key = 37 part however does not work. Yes, the pressed key is still a tab, but the state of the Shift key does not act like it is pressed. I have the KeyPreview set to TRUE in the Form. I guess I am doing something wrong here... Most likely that Shift can only be read, so it is the state when the key was pressed and it cannot be used to actually set the Shift key to a specific state. How can that be done? Any help is appreciated. *** UPDATE *** I have found the following code: Keybd_Event(VK_SHIFT, 0, 0, 0); Keybd_Event(VK_TAB, 0, 0, 0); Keybd_Event(VK_TAB, 0, KEYEVENTF_KEYUP, 0); Keybd_Event(VK_SHIFT, 0, KEYEVENTF_KEYUP, 0); This does the job. Is this the best way ? And is it "future" proof ?

It is to "jump" within different "parts" of the same control. But, if I need to it to be between or over controls, I will keep your suggestions in mind.

It's works perfectly ! Thank you very much, Remy, it is really appreciated. I wouldn't have figured it out for myself. Thanks again !!

Thanks, I understand, but as the code is inside the following if Key = VK_LEFT then begin end; it won't be executed twice.

I am not a professional programmer. I looked SendInput up SendInput function (winuser.h) - Win32 apps | Microsoft Learn But I cannot make heads or tails of it (if that's the correct expression - I am Dutch) So after some searching I found this type conversion - Delphi keypress and keybd_event - Stack Overflow Keybd_Event(VK_SHIFT, 0, 0, 0); Keybd_Event(VK_TAB, 0, 0, 0); Keybd_Event(VK_TAB, 0, KEYEVENTF_KEYUP, 0); Keybd_Event(VK_SHIFT, 0, KEYEVENTF_KEYUP, 0); With the example code I have tried to translate the Keybd_Event code. But unfortunately it does function (behave) the same. At least my application did not crash. class procedure TRoutinesEx.ShiftTab; var Inputs: array[0..3] of TInput; begin Inputs[0] := Default(TInput); Inputs[0].Itype := INPUT_KEYBOARD; // Inputs[0].ki.dwFlags := KEYEVENTF_KEYUP; Inputs[0].ki.wScan := VK_SHIFT; Inputs[1] := Default(TInput); Inputs[1].Itype := INPUT_KEYBOARD; // Inputs[1].ki.dwFlags := KEYEVENTF_KEYUP; Inputs[1].ki.wScan := VK_TAB; Inputs[2] := Default(TInput); Inputs[2].Itype := INPUT_KEYBOARD; Inputs[2].ki.dwFlags := KEYEVENTF_KEYUP; Inputs[2].ki.wScan := VK_TAB; Inputs[3] := Default(TInput); Inputs[3].Itype := INPUT_KEYBOARD; Inputs[3].ki.dwFlags := KEYEVENTF_KEYUP; Inputs[3].ki.wScan := VK_SHIFT; SendInput(Length(Inputs), Inputs[0], SizeOf(Inputs)); end; Guess I did something wrong. But I am clueless...

DevExpress Spreadsheet. Is there an option to suppress the exception message "The cell that you are trying to change is protected and therefore read-only." ? Or even better, that it does not occur at all. I can "catch" the exception, but I prefer that is does not occur at all. In WinForms there is the SpreadsheetControl.ProtectionWarning event, but this does not exist in de VCL version. I have a central exception handler in my application using the ApplicationEvents component. I can detect this exception there, but - again - it would be better it does not occur at all. As far as I can tell, there is no way I can catch the exception locally in code because the exception is triggered by the user. Hope someone has a solution.

Using Delphi Pro 11.2. The following exception messages occur frequently but not always. The important thing is, they ALWAYS occur when I close the application (the application is started in Delphi in debug mode). Project Recon.exe raised exception class $C0000005 with message 'access violation at 0x073302E8: read of address 0x62C8CA2D'. Project Recon.exe raised exception class $C0000005 with message 'access violation at 0x073302E8: read of address 0x62C8B12B'. Delphi generates a detailed map. Below a very small piece for illustrating purposes. Class 0001:00401000 017BD1B4H .text CODE 0002:01BBF000 0000B8F0H .itext ICODE 0003:01BCB000 0008C850H .data DATA 0004:01C58000 00042708H .bss BSS 0005:00000000 00000058H .tls TLS 0006:00400000 00000000H .pdata PDATA Detailed map of segments 0001:00000000 00010D80 C=CODE S=.text G=(none) M=System ACBP=A9 0001:00010D80 00000C9C C=CODE S=.text G=(none) M=SysInit ACBP=A9 0001:00011A1C 000028F4 C=CODE S=.text G=(none) M=System.Types ACBP=A9 0001:00014310 00000B2C C=CODE S=.text G=(none) M=System.UITypes ACBP=A9 0001:00014E3C 000036F0 C=CODE S=.text G=(none) M=Winapi.Windows ACBP=A9 I searched the values 073302E8, 62C8CA2D and 62C8B12B from the exception messages in the detailed map, but none of them can be found. I was hoping for a clue which component or part of the code the exception was related too. But, alas, no help here. If these exception message occur and right after I start the application again (from Delphi in debug mode) by pressing F9 without modifying anything, then all works fine. The application can be closed without any exception message. Nothing changed, but now it closes fine. In one way this good, but in another way, it is not, because it now seems even more difficult to solve the problem. When this happens, I also start the application by clicking on the executable from the Windows Explorer. I can start, do something, and close the application without getting any error. Does this scenario seem familiar to you..? Might is just be an issue with the Delphi debugger or something? In other words, the exception messages do not directly relate to mine application or code. Any help or insight is appreciated.

Sorry, I presumed from the call stack it would be clear that it is from the FastMM source code. My bad. None of my own units have a finalization section. So, it either must be from the Delphi source code, the FastMM source code or from the 3rd party source code. The good thing about it, is that it's not my code that is faulty, but the bad thing about it, is that it's way more problematic to solve (from mine point of view at least). As for the madExcept setting, I will do that. Thanks for the advice.

I hardly ever use that, but you are right. It happened again and this is the call stack. And this is the line the debugger shows: FillChar(PFastMM_DebugBlockHeader(Result).DebugFooter_FreeStackTracePtr^, LStackTraceDepth * SizeOf(Pointer), 0); As already said, it only happens when I close the application. And as far as I can tell, it does not have anything to do with my code. As I only use FasMM_FullDebugMode.dll in debug mode (no pun intended) I just must except this as an inconvenience. BTW, I also installed madExcept but it did not report an exception. That might have to do with the option "enable IDE exception catching" which I did not enable. Not sure, though. Thanks for your help. If you have any other input, again, it is much appreciated.

This is spot on. Though I don't use Error Insight, the effect is of course also noticeable in Auto Completion. I never had any serious issues with LSP. But since 11.2 constantly. I kill the LSP on a regular basis now -very frustrating. Even the slightest change in a record can make the LSP go nuts. I get that in order to fix things, one must be able to reproduce the bug. But this is not some piece of code we can share and show the bug. It should not be that difficult for Embarcadero to create an example. Just put a lot of DevExpress components, TMS components (especially FlexCel for VCL), etc. in some silly project (it doesn't even have to work) and in no time they will have the same problem. They just need to make sure that the library paths reach the source code of those components.

Go to Nexus Memory Manager | NexusDB and click on Version History. This is what you see. Not too difficult to understand why someone gets the impression that it is abandoned.

I would like to receive some input from anyone who has actual and recent usage experience with Nexus Quality Suite and Delphi version 10 or 11 (not older). Stability, usability, etc. Since the product is a collection of tools, if not too much trouble, preferably comment on them separately. Any input / comment is appreciated.

True, but... the Extended type, for example, are different in 32 and 64 bit - at least in Windows. I don't know if there are other differences between 32 and 64 bit that affects the generated code. There probably are. My knowledge is limited compared to Delphi experts. For me 32 bit is fine... however, for alle purchased components and libraries I do not only want the source code, but also checks if it works in both 32 and 64 bit. Just in case Windows drops 32 bit and I need to compile in 64 bit. Just recently I was looking for a good PDF component (to create PDF files) and came across one that only worked in 32 bit, so that was a no-go.

The good news... it seems to be an isolated incident, because I cannot reproduce it. If it happens again, I will save the pas and dfm files and report it here. Depending on the outcome, will then file a QR.

Great Thanks Greetings, Fons

Hi David, I reported it to TMS. They provided a solution. However, I finally decided to base my main form on the standard TForm and not TTMSFNCRibbonForm. This of course had some impact on the visual side of how the form looks, but I am okay with the end result. Now, maximizing the form works as excepted without any tinkering. Also, as a benefit when the user changes the width of the form with the mouse, the ribbon does not flicker anymore. Greetings, Fons

Hi David, With a vanilla VCL application it is not required. I use the TMS FNC Ribbon and when maximized it covers the Windows task bar. In the Delphi Designer it looks like this. When I run the application it looks like this. This is right after using the New Item template which creates a new application and form. I did not change a single thing. Unfortunately, when maximized it covers the Windows task bar. Programming is just a hobby for me, though I do make application that are used at work (my job however has nothing to do with programming). The easiest way to fix it, was using the OnConstrainedResize event. I am not a bad Delphi programmer, just as long as it is standard Delphi code and not all kinds of trickery with Windows handles and such things. I will report this to TMS Software. For the record, I use Delphi Pro 11.1 with patch 1. My simple solution for now works with 1 monitor. At work we use 2 or more. My solution probably has unwanted effects when using a multiple monitor setup. Not sure, but probably. So, unless TMS fixes this, I will need some kind of workaround. The last resort option is to prevent the application from maximizing. Greetings, Fons

Hi Roberto, In the OnConstrainedResize event of the Form include the following: MaxHeight:= Screen.WorkAreaHeight; MaxWidth:= Screen.WorkAreaWidth; This works for me. I have only 1 monitor, so I don't know how well it works in a multiple monitor setup. Greetings, Fons

It's been a very long time ago, so my info might not be correct now, but as far as I can remember there is a bug in MidadLib that does not exist in midas.dll. As stated, it might not be the case any longer.