Plotting waves called from a root:folder location

My first strong recommendation is this ...

* Be religious about using /W=windowname and, win=windowname, ... syntax to define where things are to be found that you want to read (e.g. ControlInfo) or change (e.g. AppendText or Button or SetVariable ...).

My second suggestion is this ...

* Move all code that is in your button call to a different function (e.g. run_mybuttonprocedure()).

* Call that function as the only thing that is done from the button action (e.g. on click --> run_mybuttonprocedure())

* Put a RETURN 0 into the top portion of your run_mybuttonprocedure(). Move that return statement along until the program crashes.

* Turn on the debugger and set a break point at the previous location of the return statement before the crash. Step through and watch what is happening.

My final thought is this ...

* Find ways to break your (rather long and hard to parse) code into manageable function calls that can each be debugged and certified in their own right.

Log in or register to post comments

October 30, 2020 at 03:30 pm - Permalink

chozo

Some further tips to massively cut down your code and make it more readable (this also helps to find errors easily):

* If possible don't use SetDataFolder at all

* Move redundant code outside of loops and switches

* I get the feeling that leaning about the SDFR flag before learning the 'boring' way of working with folders might lead to some bad habits here. You can work with folders like this:

Wave internalname=root:foldername:realwavename

Instead of referencing all waves directly (which might change) and writing each name into the code, you should do this (prefeably inside the switch and then move ALL calculations outside):

Wave work1 = root:Volatilitybins:bin1

i.e., reassign work1 etc. to the correct wave and then just use work1, work2 ... inside your calculation code.

* don't use for loops for simple wave assignments such as setting some parts of the wave to zero. These things can almost always be written as one-liners with a condition statement like:

mywave = condition ? true : false

example:

mywave=numtype(mywave[p][q])==2 ? 0 : mywave[p][q]

... or directly use MatrixOp which is way more efficient.

Hope that helps.

Log in or register to post comments

October 31, 2020 at 02:52 am - Permalink

tony

I would avoid a switch with only one effective case. Consider:

Function ButtonProc_54(ba) : ButtonControl

    STRUCT WMButtonAction &ba

    if(ba.eventCode != 2)

       return 0

    endif

    // click code here

    return 0

end

Or, if you want to retain the switch for future expansion to react to other events:

Function ButtonProc_54(ba) : ButtonControl

    STRUCT WMButtonAction &ba

    switch( ba.eventCode )

        case 2: // mouse up

            AnotherFunction()

            break

        case -1: // control being killed

            break

    endswitch

    return 0

End

This will remove a level of indentation from your function and make it easier to read.

[this was already recommended by jjweimer]

Log in or register to post comments

November 1, 2020 at 02:04 am - Permalink

tony

for human readability, move variable definitions outside of switch cases.

Igor lets you get away with this, but it makes code harder to parse by eye:

    switch(n)

        case 1:

            variable foo=1

            break

        case 2:

            foo=2

            break

    endswitch

Log in or register to post comments

November 1, 2020 at 02:46 am - Permalink

Peeyush Khare

Hi All,

Thank you so much for the great advice, tips, and suggestions! I deeply appreciate it and will be sure to implement them in my codes. I also agree that I could probably organize this better by pulling out the processing components into a separate function and call it in to the mother program.

Quick question: What is the significance of the "STRUCT" syntax in a button? I ask because I notice that if I remove the STRUCT syntax, and replace it with a string statement (e.g. string ba), the code still runs alright. But obviously, I'd be missing out on some privileges that STRUCT offers.

Many Thanks and Regards,

Peeyush

Log in or register to post comments

November 3, 2020 at 08:06 am - Permalink

tony

There is a legacy form of button control procedure that looks like this:

Function procName (ctrlName) : ButtonControl

    String ctrlName

    ...

    return 0

End

A button control function that has a string as a parameter is passed the control name in the string.

New code should use a structure, even if you don't need the extra information that the structure contains.

Note that the structure control procedure is called for all events related to the button, including mouse movements. Be sure to react only to the events you care about, typically mouseup (a click).

Log in or register to post comments

November 3, 2020 at 08:24 am - Permalink

Peeyush Khare

Thanks a lot, Tony!

Log in or register to post comments

November 5, 2020 at 09:49 pm - Permalink