# Include me please

PyroGuy

Hi all...

I'm looking for some guidance with respect using 'include' files. I tried searching but 'include' is not exactly a useful key word!

My understanding is that the include file can be incorporated into a program by calling it (including it) with a line in the code # Include 'include file.axi' and that axi file will basically work like a separate section.

I was told once it is a great way to turn on or off a section of functionality in a set of code - ie if the sat channel changing part of your code was created as an AXI file, and you were having other sat issues, you could // out the #include and effectively remove that part of the code from the program to help with debugging - am I on the right track?

When creating the AXI file, do I need to declare all the variables that will be used in the include file - or can I use variables already defined in the main program?

Any other help on AXIs would be appreciated - or steer me to a thread that already has something.

Cheers!

DHawthorne

In short, an #INCLUDE is exactly the same as cutting and pasting the contents of the file at that point in your program. The compiler, when going through your code, reads the file in at that spot just as if it were part of the main code.

It is essentially a convention to make your code more manageable. If you use the same declarations or functions over and over, it makes sense to put them in an #INCLUDE. If you have a block of functions you want to easily disable, you can put them in an #INCLUDE and just comment out the line to shut it down.

If your #INCLUDE requires any declarations from the main code, it has to come after them. If it has multiple DEFINE_ sections, it has to be placed in your main code at the very beginning of a DEFINE_ section, or the very end, or it may break it up. For example, if you put an #INCLUDE in the middle of DEFINE_VARIABLES, and it ends with a DEFINE_CONSTANT section, the rest of your variable declarations after the #INCLUDE are gong to be treated as constants.

With that kind of thing in mind, you can put whatever you like in them, and they can help kep your code from becoming a big sprawling mess.

a_riot42

You may want to think about how to organize your files when you use includes. Since they exist in the same scope you can't reuse variable names. If there are dependencies between main code and includes, then commenting out things can result in compilation errors. They are really a very clunky way of organizing your files so I tend to use them just to separate the code into logical sections that have as few dependencies as possible. If there is code I want to use over and over again I put it in a module so that it is a completely separate program and I don't run into variable name issues when using it in different projects.
Paul

DHawthorne

I use include files for project specific settings, module specific settings, and global values that I implement on just about every project. Why re-type, or cut-and-paste for every job? If you make your variables and constant unique, scope is not an issue. Used properly, they are a very convenient tool.

ericmedley

a_riot42 wrote:

You may want to think about how to organize your files when you use includes. Since they exist in the same scope you can't reuse variable names. If there are dependencies between main code and includes, then commenting out things can result in compilation errors. They are really a very clunky way of organizing your files so I tend to use them just to separate the code into logical sections that have as few dependencies as possible. If there is code I want to use over and over again I put it in a module so that it is a completely separate program and I don't run into variable name issues when using it in different projects.
Paul

I use Includes a lot as well. I don't think they're clunky at all. It all depends upon what approach you're doing. For example, for times when you want to use variables from an include in the main program you can. I've never really liked that fact that getting data in an out of a module can be cumbersome. Modules are really meant to run alone with minimal comunication with the main program unless it's through the virt devices. Includes are nice because they are nothing more than a way to organize repetative code.

I'd say my use of modules vs. includes is about 50-50%.

Spire_Jeff

I also use includes often. I use them to separate code for devices. I have an include for lighting control, one for HVAC, one for distributed audio, .... I have recently started treating the includes like mini programs and where it makes sense, I keep all variables, constants, and device definitions within the include. I make use of calls and functions when I need to control or request status from the device, and I use multiple TIMELINE_EVENTs with the same TIMELINE_ID to handle feedback if necessary.

The functions and calls allow me to include files in any order without having to worry about which device need to be declared in which order and if a variable is available at compile time.

Jeff

a_riot42

Spire_Jeff wrote:

I also use includes often. I use them to separate code for devices. I have an include for lighting control, one for HVAC, one for distributed audio, .... I have recently started treating the includes like mini programs and where it makes sense, I keep all variables, constants, and device definitions within the include. I make use of calls and functions when I need to control or request status from the device, and I use multiple TIMELINE_EVENTs with the same TIMELINE_ID to handle feedback if necessary.

The functions and calls allow me to include files in any order without having to worry about which device need to be declared in which order and if a variable is available at compile time.

Jeff

I used to do this but ran into problems when I had multiple devices in the same project, which means you would have to go through and rename every single variable, constant, timeline, etc. What do you do if you have a Extron audio switch and a separate video switch with one Extron include? To me that's clunky but that's just my humble opinion. This is exactly what modules are for so I use them instead of includes.

Not sure where the notion that modules shouldn't communicate with main code came from. If so someone should tell AMX, since many of theirs work that way, as well as Kaleidescape and many others. To me, if I can get everything into modules, and use as few includes as possible I can take advantage of code reuse, don't have any scope issues, and have a lot less code to debug.
Paul

Spire_Jeff

I don't feel that modules should not communicate with mainline code, often times it just doesn't make sense to go through the work of writing a module for some solutions because I am just integrating a device module that is a little different. For example, if I'm using Lutron lighting, there are two different ways to communicate (RS232 and IP). The commands I need to send to the virtual device are slightly different depending on the communication method, so instead of changing the command every in my code, I create a CALL 'Execute Light Button Press' (PROC,LINK,KP,BTN) and then I just switch out the include file. (I must confess, this became such a common occurrence, I just used #DEFINE and #IF_DEFINED and have both sets of code in one include file.)

Also, some of my include files are simply the comm module declaration with the necessary variables needed to be passed.

Includes are just another tool in the toolbox. As is illustrated in the thread dealing with triggering an event based on time of day, there are many tools in the toolbox and they allow many different approaches to a solution. I just find myself constantly struggling with the question of: Am I doing this to truly save time or be more reliable, or simply because I can or because it's cooler this way?

As for multiple devices, it depends on the device. If we are talking about multiple cable boxes, I have a module that handles a single cable box and then my include file is simply multiple definitions of that module with the different devices and variables as needed, but I still put all of the related code into the CABLE_BOX.axi file for organization purposes.

In the end, I use includes to aid in organization and to give me blocks of code that are options that can be removed or added as the project requires with (ideally) no adverse affects to the main block of code.

Jeff

setholle

INclude files

I love using include files, if you are only doing small jobs I don't see a need. However when you have jobs with a lot of devices, it makes sense to divide the code into more manageable sizes. However if it is a device that I use a lot I just create a module for the device passing in a device and button array.
But I really like includes, you can use them over and over again and I really dislike working on someone elses code that in one source file is 50000 lines. I have cut many peoples code up into more manageable sizes.
Seth C. olle

PyroGuy

Thanks for all the input. I'll take into consideration when I start this next project. I see pros and cons from many people. I guess personal preference reigns supreme!

I'll see how it goes.

Cheers!

Auser

a_riot42 wrote:

I used to do this but ran into problems when I had multiple devices in the same project, which means you would have to go through and rename every single variable, constant, timeline, etc. What do you do if you have a Extron audio switch and a separate video switch with one Extron include? To me that's clunky but that's just my humble opinion. This is exactly what modules are for so I use them instead of includes.
...
Paul

But don't forget that you can #include common functionality in the module!

Extron routers are a perfect example. The boffins at Extron seem to like to change their protocol slightly for every single device just to keep us on our toes, but at the end of the day a switcher is a switcher (unless it's a presentation switcher, but that's another story).

So you have an MPX switcher and an MPS switcher for which you want to create modules, the protocols are slightly different but they are similar devices. Or an Extron switcher and an Autopatch switcher for that matter. A good solution is to write a module for each device which #includes a router module include file providing interface functionality, debug output, etc., etc... Fixing a bug in the base functionality is reflected in all modules that use that include file. Features which are added to the base functionality automatically become available in all modules that reference that file.

The benefits can be huge, so long as you're respectful of the fact that changes you make to the common functionality may break the code that uses it and use appropriate caution (and a good CVS).

Note that this is one of the great limitations of the **other company**. It just isn't possible to write code for reusability such as is possible with NetLinx...