Question - Basic macro shell problems

[Meeply]

I can't believe I'm asking this but I've been staring at it half the night and am now blind to whatever is wrong. Just wrote a very basic hello.mac as a starter to use as an opening shell. For some reason a Sub in my #include can't be found. Has to be something stupid but I'm stumped. Help?

|: --------------------------------------------------------------------------------------------
|: Hello.mac
|:        by Meeply
|: --------------------------------------------------------------------------------------------

#include meeply.inc
#turbo 20
    
|: --------------------------------------------------------------------------------------------
|: SUB: Main
|: --------------------------------------------------------------------------------------------

Sub Main

    | declare and set variables here

    /declare i int inner
    /varset i 0

    /call FixWhile

    | Main loop
    /while (1) {

        | Do something

        /call Hello ${Me.Name}
        /break

        }

        
    :OnExit

    | cleanup here if necessary

    /echo Got to :OnExit

/return

　
|: --------------------------------------------------------------------------------------------
|: SUB: Hello
|: --------------------------------------------------------------------------------------------

Sub Hello( string Me )

    /echo Hello ${Me}

        
/return

and corresponding include file

|**************************************************************************
|*  include Meeply.inc - ripped from kissassist.mac
|**************************************************************************
Sub FixWhile

    | Need to check for plugin MQ2Bucles and unload it. Do this ASAP so can use /while commands from the start
     /if (${Bool[${Plugin[MQ2Bucles]}]}) {
         /squelch /plugin MQ2Bucles unload noauto
         /echo MQ2Bucles detected! This macro doesn't like it! Unloading ...   
     }

/return

What am I missing? Both are in the Macro dir. If I comment out the call to FixWhile it works.
Thanks.

 

[Meeply]

So it didn't like the scope of the previously declared var and flagged the next call instead of complaining about the /declare? I'm thinking global, outter, inner not global, outter, local.

As far as declaring and assigning vars, I just ripped up some macro I had started so I could make a shell to start macros with and wanted something declared and set as an example. A Main, a sub call, an include, an include call, declare vars, set vars, main while loop, use the :OnExit label etc. Besides, I imagine I will use that include in all my macros as I don't want duplicate code and want to be able to use whiles instead of goto for loops.

Thanks for spotting this one. I know enough to know if I try everything I know and don't see it hours later, I need a new set of eyes on it.

- - - Updated - - -

Hmmm, still having problems after changing the scope (clearly local is correct and inner is wrong). Boy there is something I'm not getting. Let me look at it again.

Something else is going on.

- - - Updated - - -

Step 1: Write macro shell
Step 2: add an include file
Step 3: ?????
Step 4:Profit

 

[Rooster]

For comments you need to close the multi line comments (in your include) |* comment *|

It wouldn't hurt to add an /echo to know your .inc sub was being called (it wasn't intially)

Also the sub parameters won't like extra spaces you have ( string me ) should be (string me) -- also noting, you pass a parameter to the sub but you aren't using it (or are you?) you named the parameter a TLO (bad), if you want to see if is working should be Sub Hello(string Test) and an /echo Hello ${Test}


I have read your other posts, i know you have some background in this stuff (hence some of your coding practices evident above)

the wiki has some great fundamental stuff here

|: --------------------------------------------------------------------------------------------
|: Hello.mac
|:        by Meeply
|: --------------------------------------------------------------------------------------------

#include meeply.inc
#turbo 20
    
|: --------------------------------------------------------------------------------------------
|: SUB: Main
|: --------------------------------------------------------------------------------------------

Sub Main

    | declare and set variables here

    /declare i string outer
    /varset i ${Me}

    /call FixWhile

    | Main loop
    /while (1) {

        | Do something

        /call Hello ${i}
        /break

        }

        
    :OnExit

    | cleanup here if necessary

    /echo Got to :OnExit

/return

 
|: --------------------------------------------------------------------------------------------
|: SUB: Hello
|: --------------------------------------------------------------------------------------------

Sub Hello(string Test)

    /echo Hello ${Test}

        
/return

|**************************************************************************
|*  include Meeply.inc - ripped from kissassist.mac
|**************************************************************************|

Sub FixWhile

|  Need to check for plugin MQ2Bucles and unload it. Do this ASAP so can use /while commands from the start
     /if (${Bool[${Plugin[MQ2Bucles]}]}) {
         /squelch /plugin MQ2Bucles unload noauto
         /echo MQ2Bucles detected! This macro doesn't like it! Unloading ...   
     }
     /echo No MQ2Bucles detected, good!

/return

 

[Meeply]

Thanks for the help. You've found all the issues. I just can't get over the extra whitespace causing a problem. I thought it was some myth you heard and continued it. Turns out to be true.

The comments in the include were different than the ones in the macro. I thought I was using multiple one line comments. My bad on that. MQ2's bad on not complaining a comment was not closed before EOF. At least I would have had a chance to spot it.

The call to the included sub was in the original code. So many things changed between the first draft and afterwards it's hard to say which version you saw.

The scope issue was also a problem. Just wanted a section to remind me to declare my variables even if the weren't used in this stub. At least it wasn't uninitialized.

Thanks again.

- - - Updated - - -

Just and FYI. As far as the comments go, I got used to single line comments a long time ago in C/C++/C# but they use the / char and I didn't want to use that.

It was quite common to see
//*********************
// comment here
//*********************

I wonder what the parser would do if I did that like this
||*****************
||*
||*****************

Probably would puke.

- - - Updated - - -

gse7en - just noticed you changed the comment type in the include file. Must be tired and staring at this code too long.

 

[playj]

MQ2 has a lot of warts

Another issue you might run is if you start another macro from within a macro (this is handy for chaining longer actions)

MQ2 will simply eat the first line in Sub Main of the second macro.
Usually that line contains some variable declaration so your macro breaks in all sorts of wonderful ways...

So you need to put /echo dummy just in case in Sub Main

PS I keep dreaming of someone completing that Python project for MQ: https://github.com/brainiac/MQ2Py but i think it is pretty dead

 

[ChatWithThisName]

The very first thing I noticed was

|** being used to block in the header of your include file.

|**

is an opening for block comment and must be closed. Think of it like { to start a block of code. if you don't close it then when the code is parsed you will get an unmatched bracket error. In this case to close the comment you need to type **|

|**
This is a block of information
that will not be parsed and
is only visible if you open the macro
**|

Single line commenting is done using |

|This is a single line comment.

The issue with notepad++ and block comments is that they don't block the entire section in a color you select unless you turn off the visibility of single line comments or use a double pipe ||** to start the block comment.

Therefore, your entire include file was commented out.

edit:

Read the replies after the fact. Seems I was beat to the punch and some even went as far as critiquing the rest of your macro.

/declare i int inner
/varset i 0

That can be done on a single line.

/declare i int local 0

I believe the inner bit not working was already mentioned.

when calling a sub and passing it a string as a parameter I highly recommend getting in the habbit of encasing the parameter in "Quotes" because when you pass a string with more than one word in it, even if it is a single variable, it will pass each word as a different parameter.

With that said,

/call Hello "${Me.Name}"

would be more appropriate.


Bracket out of alignment. While this is just for readability purposes. Your while loop closing bracket is out of alignment. The closing bracket should be in the same column as the / that started the while.

    |Main loop
    /while (1) {
        |Do something
        /call Hello ${i}
        /break
    }

This will help with large macros for you and others that might be helping you to read and understand the code without spending a lot of time re-organizing your indentations in a way that is readable.

You have a place for :OnExit as an echo. To actually reach on exit, you should change it to read as follows.

|: --------------------------------------------------------------------------------------------
|: SUB: Main
|: --------------------------------------------------------------------------------------------


Sub Main
    | declare and set variables here
    /declare i int local 0


    /call FixWhile


    | Main loop
    /while (1) {
        |Do something
        /call Hello "${Me.Name}"
        /break
    }


     


/return
    :OnExit
    |cleanup here if necessary
    /echo Got to OnExit
    /end

As using :OnExit the way you are currently using it will mean that it potentially could execute that code twice. IE: Code processed out of the while loop and executes the code and then arrives at /return, the macro has reached the end and will now /goto :OnExit which executes it again.
If you place the :OnExit outside of all routines then it will only ever be reached when the macro ends.