Ctrl Tab Ide Plugin

[santiago 37]

The way the Ctrl+Tab shortcut works in the Delphi IDE was always very inconvenient for me. Actually the Delphi IDE is the only program I can think of that does not navigate open documents based on the order in which they were last activated but instead on the order in which the tabs are arranged in the editor.

 

So if you are were working in DocumentPrevious and switch to DocumentNext, I am used to going back to DocumentPrevious by hitting Ctrl+Tab. But in the Delphi you will navigate to whatever document is on the right side of DocumentNext. This has always been very annoying for me.

 

Anyhow I made plugin that makes Ctrl+Tab behave to what I am used to from other programs, like Visual Studio for example.

 

Might be of use for some.

 

https://github.com/santiagoIT/DelphiCtrlTab

 

Precompiled binaries are available for Delphi Seattle, Rio and Sydney.

[Guest]

Very nice, and does work with 2010.

 

Thank you.

 

To make it work with Delphi2010 you need to fix the units names in uses clause.

One problem though: when rebuild while it is installed in the IDE, the IDE crash silently.

Edited June 7, 2020 by Guest

[santiago 37]

@Kas Ob.

Am happy it was useful for you and that you got it to work with D2010. 🙂

No idea about the crash when rebuilding the plugin.

The oldest Delphi Version I have tested it with is Seattle and that problem does not occur there.

 

I have never used D2010, that was before I got started with Delphi. If possible you could submit a pull request, might be useful for others as well.

[Guest]

OK, now my 2010 refuse to start and looks broken, while i am not sure %100 if it is your addon, i need to restore from backups, even removing it from registry didn't help.

I think you another person to confirm the bug on 2010.

[santiago 37]

@Kas Ob.

It is very simple to know if the plugin is causing the trouble. Just rename the DelphiCtrlTab.bpl file. The D2010 IDE should not be able to locate it at startup and the plugin will not be loaded.

You can also just remove the entry from the KnownPackages registry key:
<HKEY_CURRENT_USER>\Software\Embarcadero\BDS\xx.0\Known Packages

 

Let me know what you find.

 

 

[Guest]

I tried to dig deeper, there is a problem with DelphiCtrlTab on Delphi 2010, and the problem might be with Delphi itself, the addon looked at first as working fine, but it was wrongly listing the opened files, as arbitrary amount of them appear in the list, pressing CTRL+TAB may sometime trigger change of those listed files, (like listing different files also not all)

In fact may be it is Delphi or some other addons i have on my IDE, DelphiCtrlTab is working perfect on XE8 !

 

[Dinar 22]

Works great in Delphi 10.4 Sydney. Thanks! I have several suggestions for the development of the project in the future:

• When you quickly press Ctrl + Tab, the window is displayed for a moment, but switching to the last used unit does not occur.
• If the Welcome Page is open, it does not appear in the list of open modules, but switching to it occurs when iterating through all the units via Ctrl + Tab.
• Add change support the size of this window or automatically set it to size when displayed.
• Optimize the used space a bit, for example like this:

Edited June 27, 2020 by Dinar

[santiago 37]

@Dinar

Thx for the feedback.

 

You've got fast fingers :-).
I have fixed the issue when Ctrl + Tab is pressed and released almost immediately.

I will add support for resizing the Window. Once that is done I will publish new binaries to GitHub.
I will be out of town for the weekend. So it will most likely happen on Monday.

The Welcome Page issue I will have to look into. I never use that page, so I never noticed.

 

I oriented the way the file names are displayed to how Ctrl Tab works inside Visual Studio. The list view displays only the file names, no paths.
The full path for the selected file is displayed at the bottom of the list.
I find it too cluttered when the full path names are displayed.

 

 

[Dinar 22]

Thank you for the changes. The behavior of the plugin if the Welcome Page is open and its appearance can also be seen in Visual Studio Code.

Edited June 27, 2020 by Dinar
Changed the video file format to * .mp4

[santiago 37]

@Dinar

 

It is now possible to resize the form.

I have published new binaries to github.

 

I oriented my design towards Visual Studio. You are referring to Visual Studio Code which is a different product.

 

Anyhow, I like how Visual Studio Code displays the open files. It displays the FilePath to the right of the FileName using a different color.
It would indeed be nice to be able to have an option to use such a layout.

I am using a VCL TListBox to display the list of open modules. I don't think I can accomplish such a look using the VCL TListBox.

Maybe this can be accomplished using FireMonkey? I normally do GUI work in .NET and have never used FireMonkey before.

Anyhow I will look into it.

 

 

[Dinar 22]

1 hour ago, santiago said:

Anyhow, I like how Visual Studio Code displays the open files. It displays the FilePath to the right of the FileName using a different color.
It would indeed be nice to be able to have an option to use such a layout.

It would be nice to have that opportunity too. Thank you very much for the work done!

[Guest]

2 hours ago, santiago said:

I am using a VCL TListBox to display the list of open modules. I don't think I can accomplish such a look using the VCL TListBox.

It is doable and easy.

 

type
  TColorScheme = record
    PathColor: TColor;
    FileNameColor: TColor;
    SelectedBG: TColor;
  end;

const
  COLOR_SCHEMES : array [0..1] of TColorScheme =(
    (PathColor : $003853EB; FileNameColor : $000E5F3D; SelectedBG : $00EEE1D0),
    (PathColor : clGrayText; FileNameColor : clBlack; SelectedBG : clSilver));
procedure DrawColoredFileName(aCanvas: TCanvas; aRect: TRect; const aFileName:
  string; aColorScheme: integer = 0);
var
  LPath, LFileName: string;
  LPathPxLen, LFNamePxLen: Integer;
  LFNameX: Integer;
begin
  LFileName := ExtractFileName(aFileName);
  LPath := ExtractFilePath(aFileName);
    // get Path Length in Pixles
  LPathPxLen := aCanvas.TextExtent(LPath).cx;
  LFNamePxLen := aCanvas.TextExtent(LFileName).cx;
    // Draw Path
  aCanvas.Font.Style := [];
  aCanvas.Font.Color := COLOR_SCHEMES[aColorScheme].PathColor;
  aCanvas.TextOut(0, aRect.Top, LPath);
    // Draw FileName
  aCanvas.Font.Style := [fsBold];
  aCanvas.Font.Color := COLOR_SCHEMES[aColorScheme].FileNameColor;
    // over draw long path instead of hiding file name
  if LPathPxLen + LFNamePxLen > aRect.Right - aRect.Left then
    LFNameX := aRect.Right - LFNamePxLen
  else
    LFNameX := LPathPxLen + 2; //   2 pixel margin, can be constant too

  aCanvas.TextOut(LFNameX, aRect.Top, LFileName);
end;

procedure TForm10.CheckBox1Click(Sender: TObject);
begin
  ListBox1.Invalidate;
end;

procedure TForm10.ListBox1DrawItem(Control: TWinControl; Index: Integer; Rect:
  TRect; State: TOwnerDrawState);
var
  ListBox: TListBox absolute Control;
begin
  if odSelected in State then
    ListBox.Canvas.Brush.Color := COLOR_SCHEMES[Ord(CheckBox1.Checked)].SelectedBG
  else
    ListBox.Canvas.Brush.Color := clWhite;
  ListBox.Canvas.FillRect(Rect);

  if (Index > -1) and (ListBox.Items.Count > Index) then
  begin
    DrawColoredFileName(ListBox.Canvas, Rect, ListBox.Items.Strings[Index], Ord(CheckBox1.Checked));
  end;
end;

This just an example on how to do it, hope you like it, and remember to put Style of the listbox to OwnerDraw 

Two things though:

1) That code doesn't handle the different states, selected, grayed, focused...etc, this is up to you to do and learn.

2) No DPI scaling fixing or handling, for that i think we both ( you and me) need someone to explain on how to do it right, on Windows 10 and older versions.

 

Away from that, i really suggest to start with this example ( others may suggest better approach), but that is not the point, the point is after you do this, you will have way better understanding how VCL does drawing in general and its capabilities, it will be useful experience and knowledge to have.

 

the result of that code is like this

[santiago 37]

@Kas Ob.

Thank you got the info. Indeed, using owner draw it would be possible.
Did not even think about that.
I will look into this in the coming days.

[David Heffernan 2353]

This is really excellent. It works a treat in XE7. Thank you.

 

I have one very minor suggestion. I wonder if it would be prudent to add a namespace to all your unit names to avoid potential clashes. For instance, one of your units is named Main and I bet there are other packages around that use that name. With a namespace prefix you sidestep any such pitfalls.

[Attila Kovacs 631]

It's indeed promising, but there are several issues. At least with the github version, I'm not sure if it's the latest version though.

[santiago 37]

4 hours ago, David Heffernan said:

This is really excellent. It works a treat in XE7. Thank you.

 

I have one very minor suggestion. I wonder if it would be prudent to add a namespace to all your unit names to avoid potential clashes. For instance, one of your units is named Main and I bet there are other packages around that use that name. With a namespace prefix you sidestep any such pitfalls.

Am glad it is of use to you. 🙂
Very valid suggestion indeed. Will be addressed with the next update. I hope to have a new update by next week.

One thing I have noticed in the Delphi Community is that older Delphi Versions are still heavily in use. For curiosity why do you still use XE7? Is it bugs preventing you from upgrading?

[santiago 37]

2 hours ago, Attila Kovacs said:

It's indeed promising, but there are several issues. At least with the github version, I'm not sure if it's the latest version though.

The github binaries were compiled with the latest version.

What issues are you having?

There is a known issue with the welcome page which is next on my list.

[Attila Kovacs 631]

I installed from the sources, I never install binaries. I don't even have a Delphi like those precompiled versions.

I don't even get it why are they different, nevermind.

[dummzeuch 1517]

1 hour ago, santiago said:

One thing I have noticed in the Delphi Community is that older Delphi Versions are still heavily in use. For curiosity why do you still use XE7? Is it bugs preventing you from upgrading?

It's usually simply money. Delphi updates nowadays cost an arm and a leg and on top of that you also need to upgrade the 3rd party tools and components. (I just bought 3 TeeChart licenses and accounting was having a fit. 😉 )

 

Others don't want to go through the trouble of updating because they can't see the advantage. And of course, it takes time and there is a certain amount of laziness involved.

In my (the company I work for) case it's a mix of all the above. We are now in the process of upgrading to Delphi 10.2 + latest update (the last version that didn't annoy the hell out of me) after staying with Delphi 2007 for a long time due to the Unicode change. And I hope that one of the 10.4 upgrades will fix all those annoying bugs so maybe we will even upgrade to that version.

 

That process proves painful as we still need to keep compatibility to Delphi 2007 with our internal libraries because we will probably never finish upgrading all those internally used tools. There are just too many of them.

 

Oh, and then there are those who - for years - have been phasing out Delphi (because it's so 1990ies and nobody uses it nowadays) and porting their software to a different development platform, so they keep the old Delphi version around to maintain the programs that work until (in some far far way future 😉 ) the new software is actually ready.

Edited July 7, 2020 by dummzeuch

[David Heffernan 2353]

1 hour ago, santiago said:

One thing I have noticed in the Delphi Community is that older Delphi Versions are still heavily in use. For curiosity why do you still use XE7? Is it bugs preventing you from upgrading?

For me it is not money. I have later versions than XE7. For me there is no benefit to updating. Nothing released since XE7 has any significant benefit for me. For sure there are some minor things but nothing that really makes it worth the effort. 

 

And it is an effort for me because I have a whole bunch of patches that I apply to the RTL to address design flaws primarily in its handling of floating point. That requires bespoke code for each version and I don't currently think it is worth it.

 

Plus I'd have to spend some time working with multiple versions because I need to maintain recent releases of our software.

 

Now, if Emba did something about the very poor performance of the compiler code that dcc64 emits, I would upgrade without hesitation. 

[santiago 37]

33 minutes ago, David Heffernan said:

And it is an effort for me because I have a whole bunch of patches that I apply to the RTL to address design flaws primarily in its handling of floating point. That requires bespoke code for each version and I don't currently think it is worth it.

Thx. for the info!

In case you have reported this, would you mind sharing the QC issue link(s)?

[David Heffernan 2353]

1 hour ago, santiago said:

Thx. for the info!

In case you have reported this, would you mind sharing the QC issue link(s)?

QC107411

 

But QC is dead. Or did it come back to life?

[santiago 37]

1 minute ago, David Heffernan said:

QC107411

 

But QC is dead. Or did it come back to life?

No idea how its called then.

This is the root url: https://quality.embarcadero.com

[David Heffernan 2353]

Yeah, that's Quality Portal, the new place for reporting bugs. I submitted loads of reports at the old place, Quality Central, and then Emba killed it, along with all the bug reports. We were asked to resubmit the reports that we cared most about. Which was a load of work that I couldn't face. 

[Lars Fosdal 1793]

What happened to that document?
https://web.archive.org/web/20171221023547/http://qc.embarcadero.com/wc/qcmain.aspx?d=107411

 

Edit: I took the liberty of splitting David's answer into a new thread.