Not all included files are opened

[Tommi Prami]

Hello,

I have configured Inno to upen all files automatically, but many of the files are not opened.


Most of the time it is OK, but now I need to debug a file that is not opened.

Can't quite figure out why there is no separate "Open included file..." functionality. Also now would help if I could set breakpoint into the Preprocessor output-file, but it seems that I can't.

Files that are not opened into the IDE are included fine into the  Preprocessor output-file, and the installer compiles and works fine.

Is there anything I could do to get the file(s) opened into the IDE? 

-tee-

[Martijn Laan]

Hi,

How many include files do you have? It supports opening up to 20 of them.

If you have less but not all appear, it's likely you have closed them before, and you can reopen from the View menu, or the status bar, or by right clicking a tab.

Greetings,
Martijn

Op 2-12-2025 om 06:31 schreef Tommi Prami:

Hello,

I have configured Inno to upen all files automatically, but many of the files are not opened.

Most of the time it is OK, but now I need to debug a file that is not opened.

Can't quite figure out why there is no separate "Open included file..." functionality. Also now would help if I could set breakpoint into the Preprocessor output-file, but it seems that I can't.

Files that are not opened into the IDE are included fine into the  Preprocessor output-file, and the installer compiles and works fine.

Is there anything I could do to get the file(s) opened into the IDE? 

-tee-

--
You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/CABwd-apOpBsPjiffr_Gv2q59Hoo4ZNqzc7x2zhmOCh-D-4EBMA%40mail.gmail.com.

[Tommi Prami]

Hello,

I was thinking that there could be a hard limit of tabs. 

I checked and think I have 38 files. While back, refactored project into smaller files, instead of massive ones.

-tee-

To view this discussion visit https://groups.google.com/d/msgid/innosetup/176466744546.7.12476005983070889402.1041946330%40innosetup.nl.

[Tommi Prami]

Yellow,

Could you increase the upper limit please? 

-tee-

On Tue, Dec 2, 2025 at 11:24 AM 'Martijn Laan' via innosetup <inno...@googlegroups.com> wrote:

To view this discussion visit https://groups.google.com/d/msgid/innosetup/176466744546.7.12476005983070889402.1041946330%40innosetup.nl.

[Martijn Laan]

Hi,

I don't know. To be honest, the limit of 20 already sounds like quite a lot.

The limit is there because supporting more comes with overhead (more Scintilla instances, even if you don't have extra include files), and the IDE is also missing functionality to navigate many files. For example, the tab control has no special features for handling large numbers of tabs, nor is there something like a dialog that lets you enter a filename and jump to it.

Greetings,
Martijn

Op 5-12-2025 om 09:52 schreef Tommi Prami:

To view this discussion visit https://groups.google.com/d/msgid/innosetup/CABwd-aprMBnr6_5vUtvURBS9DLMT413RtKqro6GaH8xehZGoJw%40mail.gmail.com.

[Tommi Prami]

Chello,

Would not hurt to try right? And if hurts, it only hurts those that have lot of files, like me.

Don't know is there some technical difficulties. At least for me IDE does bot hog resources, CPU or memory. I am OK if it eats 8 cores and 10gb of memory.

In Other hand I am not OK the fact that I could not debug code, and had to use 20x more time to find it by reading code on external editor.

Also I can close all the tabs I am not interested at the moment. Now I have no way to fo that.

...Or would be OK also if files not opened automatically, would be listed in closed tabs list, and if 20 is open and click one to open it, it would give error message or something like that.

-tee-

To view this discussion visit https://groups.google.com/d/msgid/innosetup/176493300762.8.13230591379981537562.1048642059%40innosetup.nl.

[Gavin Lambert]

On Saturday, December 6, 2025 at 12:10:14 AM UTC+13 Martijn Laan wrote:

I don't know. To be honest, the limit of 20 already sounds like quite a lot.

The limit is there because supporting more comes with overhead (more Scintilla instances, even if you don't have extra include files), and the IDE is also missing functionality to navigate many files. For example, the tab control has no special features for handling large numbers of tabs, nor is there something like a dialog that lets you enter a filename and jump to it.

How hard would it be to add a menu item to the right-click menu when the cursor is on a #include line to make it open the corresponding file?  To me, the preferred behaviour would be to show only the main and preprocessed file (not open included files by default) but have an easy way to open them on demand.

Another (perhaps better, since it doesn't require hunting down the #include line) option might be to have a menu item (either via submenu or popup dialog) that supports any number of included files that can be opened on demand rather than auto-opened. 

[Martijn Laan]

Hey,

Op 7-12-2025 om 23:40 schreef Gavin Lambert:

To me, the preferred behaviour would be to show only the main and preprocessed file (not open included files by default) but have an easy way to open them on demand.

They only open by default the first time a new include file is encountered. After that, once you close them, they stay closed across sessions, and you can reopen them via the three ways I mentioned.

How hard would it be to add a menu item to the right-click menu when the cursor is on a #include line to make it open the corresponding file? 

Even though the IDE doesn't have a parser and doesn't understand much about scripts, I'm sure it could be made to detect a right-click on an #include line. It would then also have to do something special when that include hasn't been encountered before, like adding a new tab, in the right position, with an empty file.

But for me the question still is: why is 20 not enough? And if 20 is not enough, then what number would be enough? Making it work to support an unlimited amount is not an option right now, because it would involve major refactoring.

To me, having 38 include files like OP sounds a bit odd. But maybe I just underestimate how complex scripts can be.

Once I know what number would be enough, I can check what that means for resources. Like I said, even if you don't use any include files, the memos are still there, just hidden. 

Greetings,
Martijn

[Gavin Lambert]

On Tuesday, December 9, 2025 at 3:48:21 AM UTC+13 Martijn Laan wrote:

Op 7-12-2025 om 23:40 schreef Gavin Lambert:

To me, the preferred behaviour would be to show only the main and preprocessed file (not open included files by default) but have an easy way to open them on demand.

They only open by default the first time a new include file is encountered. After that, once you close them, they stay closed across sessions, and you can reopen them via the three ways I mentioned.

If I turn off the setting to automatically open include files, there are no menu options to open specific ones in tabs afterwards.

If I turn on that setting, then it does automatically open a bunch of files (which I don't really want, since I have a lot of different top-level files that usually share the same include files that very rarely need modification).  If I close those tabs, then menu options do appear to reopen them, but I suspect that Tommi's issue is that if there are more than 20 such files it won't show the rest of them.

But for me the question still is: why is 20 not enough? And if 20 is not enough, then what number would be enough? Making it work to support an unlimited amount is not an option right now, because it would involve major refactoring.

To me, having 38 include files like OP sounds a bit odd. But maybe I just underestimate how complex scripts can be.

I'm not sure if this is what Tommi is doing, but there was some advice a while ago to make separate files for each custom wizard page to keep things together (and perhaps allow the use of designer tools).  It's also not uncommon to make separate includes for each dependency library so that you can just include a common script in each app-specific script that uses the same dependency.  These could add up for a complex app.  Or maybe it's just a coding style preference.

Once I know what number would be enough, I can check what that means for resources. Like I said, even if you don't use any include files, the memos are still there, just hidden. 

Why not just save an unlimited number of files without creating any corresponding memos/tabs (just the menu items to open them), then create the UI on demand?  That should avoid resource concerns.  Then the setting could just control whether it initially opens all of them or not, so you don't have to close them all manually.  You could still have a max number of simultaneously open tabs and ask the user to close some of them before opening more.

[Gavin Lambert]

Mere moments ago, quoth I:

If I turn off the setting to automatically open include files, there are no menu options to open specific ones in tabs afterwards.

Hmm, actually the behaviour is weirder than that.  With the setting off, on loading a script (with only four included files) it does not show any tabs at first.  Then I compile the script, and it opens the preprocessor output tab but nothing else, but the menu options appear to open tabs for three of the four files.  Possibly of note is that the one it does not include is the one that currently reports a compile error (but this didn't stop it auto-opening when the setting was on).  Fixing the error and compiling again does not make it appear.

Ah, I see.  If I have the setting on and then close only some of the tabs, when I later reload the script with the setting off and then compile, it offers to reload only those tabs I had previously closed, without showing the ones that had been open.  Selecting to reopen any of these will delete the menu item but not reopen the tab, until I turn the setting back on.  This is still pretty weird behaviour though.

I'm currently testing this in 6.4.3, in case that's something which has been fixed since then.

[Andrew Truckle]

It doesn’t open all files for me either. To me:

1. Preprocess is a must. 

2. Others opene on demand via right click and

3. Maybe bespoke dynamic popup window accessed by menu of all linked files. From there it ku go to that file in open or new tab. 

Of course debugging g should ideally allow stepping into these files as the source is present. But that is a nicety. 

[Martijn Laan]

Hi,

Op 8-12-2025 om 23:28 schreef Gavin Lambert:

Why not just save an unlimited number of files without creating any corresponding memos/tabs (just the menu items to open them), then create the UI on demand?

I'm sure that sounds like something that could be done easily, but like I tried to explain, unfortunately it's not.

Then the setting could just control whether it initially opens all of them or not, so you don't have to close them all manually.

Such a new setting could still be added. I'm not sure how interesting it is though, as it only opens many include files in an unexpected way if you get the script from someone else and the IDE hasn't seen it before. Even then, you can still close all easily by selecting the first and holding Ctrl+F4. Could add a 'Close All' option though.

Greetings,
Martijn

[Martijn Laan]

Hi,

Op 8-12-2025 om 23:44 schreef Gavin Lambert:

Ah, I see.  If I have the setting on and then close only some of the tabs, when I later reload the script with the setting off and then compile, it offers to reload only those tabs I had previously closed

Thanks. The check which determines if it should show the menu items to reopen tabs is incomplete. It looks at the setting only indirectly and insufficiently. Will fix.

Greetings,
Martijn

[Gavin Lambert]

On Tuesday, December 9, 2025 at 8:55:40 PM UTC+13 Martijn Laan wrote:

I'm sure that sounds like something that could be done easily, but like I tried to explain, unfortunately it's not.

You said that currently the tabs+editors still exist, just hidden.  I was suggesting not creating them in the first place until explicitly requested to open.  Unless I missed another explanation?

I would think that it'd just mean creating a menu item for each file instead of an editor.  Obviously there's no particular performance benefit if it then also auto-opens everything, but that's another reason I would prefer that the default behaviour (or at least the selectable behaviour) is to not open anything until demanded (either by user action or e.g. to show a compile error or for debugging).

 

Such a new setting could still be added. I'm not sure how interesting it is though, as it only opens many include files in an unexpected way if you get the script from someone else and the IDE hasn't seen it before. Even then, you can still close all easily by selecting the first and holding Ctrl+F4. Could add a 'Close All' option though.

Perhaps my usage is unusual in a different way, but I have about 50 or so top-level iss files (for different apps, or sometimes different bundles of apps), almost all of which share the same three or four include files (plus a few others that are more unique) and which almost never need to be edited.  So it's a distraction to have to keep closing tabs when loading a top-level script for the first time.  I don't have that many that this is a big issue, but still, it's nice to have a tidy workspace.

[Martijn Laan]

Op 10-12-2025 om 00:20 schreef Gavin Lambert:

You said that currently the tabs+editors still exist, just hidden.  I was suggesting not creating them in the first place until explicitly requested to open.

Yes, I understand. But not creating them in the first place is highly problematic for the current code base. It’s not by accident that it doesn’t already work like that.

Perhaps my usage is unusual in a different way, but I have about 50 or so top-level iss files (for different apps, or sometimes different bundles of apps), almost all of which share the same three or four include files (plus a few others that are more unique) and which almost never need to be edited.  So it's a distraction to have to keep closing tabs when loading a top-level script for the first time.  I don't have that many that this is a big issue, but still, it's nice to have a tidy workspace.

Okay, thank you for the explanation. I will look into adding the option. I don’t think it would trigger when loading a top-level script for the first time, though. Instead, it would trigger when the compiler encountered an include file for the first time.

I will also look into increasing the limit to 40, though I hope Tommi will still answer the earlier questions.

Greetings,
Martijn

[Andrew Truckle]

How about a workspace approach. As bit like vs code? It just remembered the state of what files were opened? That and the preprocessed I don’t necessarily need the see the linked files, but to open on demand is nice. But then maybe just a panel on the side with tree hierarchy. Much like vs studio solution explorer. Then you can just click a file in the tree to open it. Might be nicer ui than menu approach?

--
You received this message because you are subscribed to a topic in the Google Groups "innosetup" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/innosetup/qsd5nTdYdlY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/176535414524.8.13904755090728663640.1057497566%40innosetup.nl.

[Tommi Prami]

Hello,

We have two applications that have basically only main script file that is their own. Those setup variables etc. 

All sections are included as include. and that has common includes.

like 

[Code]
#include "..\common\CodeSection.iss"

and  CodeSection.iss

[code]
// CodeSection.iss

#include "..\common\Windows.iss"
#include "..\common\WindowsVersion.iss"
#include "..\common\SystemtimeUtils.iss"
#include "..\common\FileUtils.iss"
...

Most of the sections in the main script have only one include with all needed stuff there. Code is way more complex than the rest combined.

There are external libs, which might have their own includes. And as said, we have tried to refactor all code into the logical files that have code that some has commonality. Like "#include "..\common\StringUtils.iss""

There are 38 files now.

You received this message because you are subscribed to the Google Groups "innosetup" group.

To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/innosetup/CAKSr1pfkrn6rpCj_BU-7HPEVu5nMpPtacQjE8VzuROGhC8QByA%40mail.gmail.com.

[Tommi Prami]

"I will also look into increasing the limit to 40, though I hope Tommi will still answer the earlier questions."

I tried to answer all the questions, if there are some open questions, let me know.

-tee-

--

You received this message because you are subscribed to the Google Groups "innosetup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to innosetup+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/innosetup/176535414524.8.13904755090728663640.1057497566%40innosetup.nl.