Fons N

On 9/22/2023 at 11:24 PM, GringoStarr said:

new to Delphi Pascal
and it's hard to find good examples on how to use Excel Automation

I found this website to be very helpful.

https://www.physiologyweb.com/delphi_code_examples/microsoft_excel_automation_with_delphi.html

6 hours ago, David Schwartz said:

But if whatever you've seen makes you think you'll be better off with OCR libs that are set up as DLLs

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.

21 hours ago, David Schwartz said:

It's a component written in Delphi and runs incredibly fast. NOT A DLL!

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).

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?  

Sorry. 

On 1/30/2023 at 9:53 AM, Fr0sT.Brutal said:

If you just want to jump over controls by cursor arrows, it's easier to post crafted messages to a form via PostMessage or Form.Perform

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.

On 1/30/2023 at 7:06 PM, Remy Lebeau said:

Try this instead:

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

On 1/28/2023 at 2:44 PM, programmerdelphi2k said:

Therefore, I think it would be better if you make the change outside the event. And using a function like Keyb_Event() (outside the event), would be something more sensible!

 

REMEMBER: the event can be called many times... in case, OnKeyDown is called as many times as the keys pressed!

Thanks, I understand, but as the code is inside the following

  if Key = VK_LEFT then
  begin
  end;
 

it won't be executed twice.

17 hours ago, PeterBelow said:

you should use SendInput instead

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...

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 ?

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.

19 hours ago, FPiette said:

You didn't mentioned in which source code file this happens. Is it yours or in FastMM source code?

The last line you show in the call stack tells that the exception occur in one of the finalization section in one of the unit.

For madExcept, be sure to check "Report resource leaks" and "instantly crash on buffer ... overrun" if "overrun" doesn't give any error, try with "underrun".

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.

19 hours ago, FPiette said:

You said it runs under debug. If so, the IDE should show you the exact line of error if it happen in your code. It also show the call stack

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.

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.

11 hours ago, Dave Nottage said:

The resolution for the original report there is "cannot reproduce", which is accurate, given that the report claims that LSP does not work at all. This is a much more accurate report: https://quality.embarcadero.com/browse/RSP-39380

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.  

On 9/28/2022 at 10:01 AM, eivindbakkestuen said:

Not sure where the abandoned impression comes from

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.  

3 hours ago, David Heffernan said:

You can have a project with both 32 and 64 bit targets.

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. 

1 hour ago, Uwe Raabe said:

If anyone experiences this, it would be helpful to capture the current state of the unit. Then we can inspect these units to detect similarities.

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.

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?

19 minutes ago, David Millington said:

Bookmarks and Navigator are now here:

Great  Thanks 

Greetings,

Fons

On 5/14/2022 at 10:34 AM, David Heffernan said:

This should not be necessary.

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

4 hours ago, David Heffernan said:

This should not be necessary. It also seems like there would be scenarios which this would stop the user doing things they want to do. 

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

40 minutes ago, Uwe Raabe said:

Not when you add MidasLib to the uses clause.

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.