10 replies to this topic

[Taco Bell]

Today I started to break up my main setup.rul into separate scripts and to try include those new pieces (i.e. Visio.rul, Visio.h, etc.).

However I'm having some difficulty to get the compiler happy.  I either get redefinition or undefine errors.

If someone could help me with the structure/syntax I would greatly appreciate it.

Here's what I've got so far:

For setup.rul:
#include "project.rul"
#include "Visio.rul"

For project.rul:
#include "project.h"

For Visio.rul:
#include "Visio.h"
#include "setup.rul" // SINCE IT MAKES USE OF ITEMS IN MY MAIN SCRIPT

With this setup I get a lot of redefinition errors and I can understand that, but if I remove that last setup.rul reference, then it doesn't understand any of the stuff I'm still/currently borrowing from my main script.

Prior to all this I just had the project.h and project.rul which were self contained and therefore easy to include.

[EberhardH]

I'm sure the compiler behaves correctly because you really offer some redefinitions (and even in a cyclic manner)!

The compiler sees the whole lot as just one portion of code named "setup.rul", independent of the number and names of files that were included in it. The "setup.rul" is the main script to compile. So why do you once again include setup.rul into visio.rul?

Your structure will be like this:

setup.rul
    project.rul
         project.h
    visio.rul
         visio.h
         //setup rule is already there (as frame)

Just make sure all functions are prototyped prior to their definition.  -  I cannot imagine why the compiler should have difficulties with not understanding the (as you describe them) "borrowed" parts. Try this: duplicate your whole project and substitute the #include statements with the real contents of the single files, and have the compiler run once again. Does it work?

[Taco Bell]

Yes, I understood the cyclic redefenitions, but I was trying many different combinations in order to try and make the compiler happy.

I even tried you structure initially, and several times later, without success.

However, just for kicks I gave it another try.  I could only get it to work though, so long as I call those includes AFTER all of setup's delcarations (i.e. #define, globals, prototypes) which is NOT at all what I expected.

[Blake Miller Wonder]

At the top of Setup.Rul I place #include "ifx.h"
followed by inclusion of all the other H files my project uses.

Then at the end of Setup.Rul I place #include "ComponentEvents.rul"
followed by all the other RUL files my project uses.

This seems to work great.

The H files only have function prototypes and declarations of definitions and global variables.

The RUL files only have code in them.

[Taco Bell]

Thanks for the reply BMW.  I value your opinion.

First off my new RULs & Hs and broken down as you describe.

As for my setup.rul's structure, I ended up having the ifx.h inclusion at the top and then just my new RUL inclusions after the prototype declarations.  This is due to the fact I don't have any Hs which exist on their own.

If I understand you correctly though, if you have the files Code.h and Code.rul, then you would list both the H file above and the corresponding RUL file below.  Is that correct?  Or did you mean that JUST the H files which exist on their own?  Let me know.

[Blake Miller Wonder]

All my files are eventually included within setup.rul.

The general structure of my setup.rul files is like this:


#include "IFX.H"
#include ...ALL my other header (*.H) files I need...

Setup.Rul file's source code.....

#include ...InstallShield generated source files (*.RUL)...
#include .. All my other required RUL files...


Any time I have a RUL file I made with some functions in it I put the function 'prototype' statements into a header file somewhere.

Sometimes I make an 'X.H' for an 'X.RUL' and other times I just bulk all my 'prototype' statements into a single header file I call setupfuncs.h.  It just depends upon how reuseable I think the functions in a particular RUL file are from one project to another.

[prozacrefugee]

Do you have your functions prototyped within your rul files?  If not, you will have to include the h files before the main portion of your Setup.rul code.

Also, make sure you have added the files to your project as well as #include ing them in your script.

[Taco Bell]

prozacrefugee: I'm guessing you're asking me this question even though I did get my stuff working, just not in a way I was expecting.  Especially since the help is essentially worthless on this subject

However, I've found it difficult to describe how things are exactly setup, so I'll pass at attempting to do so yet again.

[stevebc]

try putting the following in your headers.
e.g.


#ifndef _HEADER_H_    // first line of code
#define _HEADER_H_


// add body of code here

#endif       //end of file



I usually make the define same name as the header file. So for example above the file was called 'header.h'


Cheers
Stephen

[Taco Bell]

Okay, thanks.  I'll try that and see if it helps.

The reason this all came up is I had to create a setup for a new product which used a subset of an existing product's tools, but under a different name.  Therefore, a lot of it was the same, but also a lot of it was different.

Under this new install I'm still including way more than I need, but anything less and the compiler barks at me with warnings and/or errors, so one day I'm gonna just have to spend some time trying to truly understand this.

You think it would be easy for me since I've used the same kind include concept in various other languages (i.e. C++, Java, Basic, etc.), but I'm obviously missing something.  Oh well, I enjoy a challenge.

[Taco Bell]

For what it's worth, I was playing around with different combinations for a new product and finally got something working, that makes sense to boot.  Thanks for the help guys.