Separate Formatter Issue/Warning..

[Ian Branch 127]

Hi Team,

Windows 11, D11.3 (and previous D11 versions, don't recall experiencing the issue in D10 versions), latest GExperts.

This is as far as I can tell NOT an issue with GExperts Formatter.

 

I have for some time been wrestling with the Formatter sometimes working & sometimes not.

I was initially blaming it on other plug-ins.

This turns out to not be the case.

I use a Drive/Directory utility called Xplorer2.  It is excellent.  One of the things I like most about it is that its open drives/directories are persistant between uses.  Unlike Windows Explorer.

Anyway, after a lot of experimenting with the various Appliations I use while developing, I have discovered that if I open Xplorer first, it does something such that when I open Delphi and go to use the GExperts Formatter, the Formatter is disabled.  Totally. 😞

If I open Delphi then Xplorer, then the Formatter is fine.

It is now a matter of discipline in the order of opening files.  🙂

Just thought that may help others in some way if they are experiencing an issue like I was.

 

Of course this could be just unique to my development environment.

 

Regards,

Ian

Edited March 1, 2023 by Ian Branch

[dummzeuch 1505]

What exactly do you mean by 

11 hours ago, Ian Branch said:

go to use the GExperts Formatter, the Formatter is disabled.  Totally.

? Is the menu entry disabled? Is it enabled but the formatter does nothing? Do you get an error message? Any message at all?

 

I simply can't imagine what this tool might do that prevents the GExperts formatter from working. Maybe setting the editor buffer to read only? But then you wouldn't be able to edit your code.

[timfrost 78]

I have Xplorer2 installed and I cannot reproduce any problem with the GExperts formatter when starting Delphi second (or first).  I have gone back to Directory Opus and no longer use X2, so if it was intermittent I might not have noticed it.

[Ian Branch 127]

Hi Thomas,

Neither the menu option or the Hot-Key work.  No error messages, it just sits there. 

I don't understand it either however I don't believe it to be a GExperts issue.  

 

Hi Timfrost,

Tks for that feedback.  It is repeatable here.   I guess it is something in/with my overall PC environment.  😞 

 

Anyway, I have identified it and have a work around.

 

Regards,

Ian

[dummzeuch 1505]

19 minutes ago, Ian Branch said:

Hi Thomas,

Neither the menu option or the Hot-Key work.  No error messages, it just sits there. 

I don't understand it either however I don't believe it to be a GExperts issue.  

 

Hi Timfrost,

😞

Could you please add e.g. a messagebox call to the expert's execute method and check whether it shows that message?

Edited March 2, 2023 by dummzeuch

[Ian Branch 127]

Sure.  Which Unit would that be in?

[dummzeuch 1505]

1 hour ago, Ian Branch said:

Sure.  Which Unit would that be in?

Source/Formatter/GX_CodeFormatterExpert.pas

 

Or even earlier:

 

Source/Formatter/GX_eCodeFormatter.pas

Edited March 2, 2023 by dummzeuch

[Ian Branch 127]

Hi Thomas,

OK.  At first efforts/tests, I can't make it fail with this added.

  FormattedBlockEnd: string;
begin

  ShowMessage('In Execute Method');


  Result := False;

  if not GxOtaTryGetCurrentSourceEditor(SourceEditor) then
    raise ECodeFormatter.Create(str_NoEditor);

The message shows every time and the Formatting works.

I will try all sorts of permutations today and let you know the results.

 

Regards,

Ian

[Ian Branch 127]

Hi Thomas,

Hmmm.  Thinking out loud.  Perhaps another variable in the environment.

GExperts has historically been the first thing I install in a new Delphi.  Then all the other Add-ons and libraries.

During my initial testing I removed all the Ad-ons and still experienced the issue.

Now, I have left all the Add-ons installed and removed/re-installed Gexperts and it seems to be fine.

 

We shall see after a day of testing.

 

Ian

[Ian Branch 127]

OK.  I have it happening.. 😞

The message is showing but the formatting isn't happening..  😞

I closed one project, it was working, opened another and it isn't.

Closed and reopened Delphi and the Project and its working again.

Close that project, open another, still working..

Confusing, frustrating, annoying...

 

[timfrost 78]

I have once seen that symptom.  No formatter, close, open, formatter; and vice versa.  Only once. No involvement of Xplorer2.  It was before I upgraded from 11.2 to 11.3, and I think I put it down to running the IDE as admin.  In 11.3 I made sure to run the GExperts install batch file as admin, after I had rebuilt GExperts as mentioned in another thread.

 

[dummzeuch 1505]

8 hours ago, timfrost said:

In 11.3 I made sure to run the GExperts install batch file as admin, after I had rebuilt GExperts as mentioned in another thread.

 

It shouldn't matter whether you run that batch file as admin or not. It only adds entries to HKCU in the registry.

[dummzeuch 1505]

8 hours ago, Ian Branch said:

OK.  I have it happening.. 😞

The message is showing but the formatting isn't happening..  😞

I closed one project, it was working, opened another and it isn't.

Closed and reopened Delphi and the Project and its working again.

Close that project, open another, still working..

Confusing, frustrating, annoying...

For me it's mostly annoying, because I have no idea what could cause this. Maybe the formatter itself works but writing the formatted code back to the edit buffer doesn't? I'm not sure how good the error handling is there. I haven't looked at this code for ages.

[Ian Branch 127]

Hi Thomas,

Still with the issues. 😞

Sometimes when it doesn't work, it still shows the message box, if I reboot and restart Delphi it does work..

Unpredictable. 😞

 

Ian

[dummzeuch 1505]

If you haven't already, please file a bug report on sourceforge. Make sure to include what you already tried and also the source code changes you used for that.

 

I look into those bug reports regularly and have recently fixed quite a lot of them. But I tend to forget about bugs only reported here.

[Ian Branch 127]

Done.

https://sourceforge.net/p/gexperts/bugs/314/

[timfrost 78]

I am now back to getting this problem also.   Not yet managed to find a trick to make it work.  

It fails to run with the defined keystroke (I have tried defining others without success) and with the menu.

Edited March 9, 2023 by timfrost

[Ian Branch 127]

Please add your experiences/testing to the bug report on Sourceforge.

Every little bit of info will help Thomas.

[dummzeuch 1505]

I have just committed revision #3989 containing additional debug messages that should help tracking down the reason for the failure. Please update your sources and compile a new DLL in debug mode(!). Then, the next time formatting failed, check the topmost entries in the GExperts debug window (in the icon tray). And copy them to the bug report. Please start with the line saying
TeCodeFormatterExpert.Execute
and include all lines above that start with the string "GXFormatter:".

[Ian Branch 127]

Build of 3990 failed - See Bug Report.

Edited March 11, 2023 by Ian Branch

[dummzeuch 1505]

14 hours ago, Ian Branch said:

Build of 3990 failed - See Bug Report.

You seem to have had merge conflicts.

Your second try with a fresh check out did not compile because you compiled it with the release configuration. With the debug config it would have compiled. You need to use the debug config because otherwise no messages will be written to the log.

 

(I have also just committed revision #3991 which fixes the compile error in release mode.)

[Ian Branch 127]

Yup.  My goof.  😞  Working the latest now.

[dummzeuch 1505]

Ian and I have tried to track this problem down and at least succeeded in finding where it happens:

 

It's in unit GX_CodeFormatterFormatter, method TCodeFormatterFormatter.doExecute. There is a while loop at the end of that method that is supposed to remove any additional CR/LF at the end of a unit:

  // remove empty lines from the end
  FTokenIdx := FTokens.Count - 1;
  while (FTokenIdx > 0) and TokenAtIs(FTokenIdx, rtLineFeed) do begin
    FTokens.Extract(FTokenIdx).Free;
    Dec(FTokenIdx);
  end;

Somehow FTokenIdx (which is an integer field of that object) shows as a large negative number in the debugger, even though, as you can see, it is initialized properly. Then the while loop is entered even though the condition FTokenIdx > 0 is not met. Again that's according to the debugger. After executing that loop for a time it causes an access violation. That access violation is silently swallowed by an exception handler of one of the calling methods (yes, you can blame me for not writing a proper exception handler there) and the formatted code is not inserted into the edit buffer.

 

Turning off optimization for that unit makes the issue disappear which seems to point to the Delphi 11 compiler as being the culprit here.

 

Unfortunately I am not fluent enough with reading assembler code to find out what the actual problem is. And since it only ever happened once on my computer I can't really debug it and writing a bug report without any further info will probably pointless. If anybody with better knowledge in that area wants to step in, I would be grateful. 

 

For now, I have completely disabled optimization in Delphi 11 for that unit. That change was committed to revision #4003 and #4004

Edited March 25, 2023 by dummzeuch