Do you like the predefined variables?

[Cory]

I am not a fan of the predefined 'old school' (%T[1])%) variables one gets when creating a new macro. Since we now have properly named variables I do not see the need to include them with every new macro because if it's new there's no need for reverse compatibility. It's become an annoyance for me that every time I create a new macro I have to go to the variables tab and delete them. Someone once suggested I just leave them in but the first time one tries to use the variable debugger you're lost. I was using some templates for awhile but if one just needs a simple quick macro that too adds steps. Will you join with me in petitioning ISS to change this at some point in the future? Just add your vote by responding here with your comments.

[paul]

Good idea.

[Rustywinger]

John Hancock

[terrypin]

I'm not sure I follow you on this Cory. Is there some penalty in performance due to these built-in variables? When asked to specify a variable in a new command I find it handy to be offered say 'N[]' and I just enter the '1' to get '%N[1]%' as the result. Of course, sometimes I will want to use the extra flexibility now available, and give a meaningful name of my own, such as %CountLines% or whatever, although that requires a few extra keystrokes. A minor downside is that I then have to scroll down the unused 99 N or T variables to find it in the Variable Debugger.

 

--

Terry, East Grinstead, UK

[Cory]

There is no downside to performance as far as I'm aware of. The main performance reason is in debugging. Try to watch text variables named %First Name% and %Zip Code% when running a debug. You will find 99 T variables in between. Also I consider it bad form to use arrays for unlike variables. But more importantly one has to keep a secret decoder ring handy when using them this way. IMHO there is no reason to use the built in array variables now that we have named variables. So for me they are just in the way and I have to delete them every time I create a new macro and I think this is an annoying waste of time.

 

BTW to create a new variable try this. When you have to enter a variable name just type "Count" and hit OK. When the dialog closes it will ask you if you want to define this variable and even guesses that it should be an Integer. Just hit "Enter" and you're done. What could be more simple? And now you have a variable that makes sense instead of N[36] which you will not remember 5 minutes form now. And if you do want to continue to use old array style variables that's just a easy to create. So I guess what I am saying is that as long as some hold on to the old ways this will be inefficient for some of us. I just think the time penalty should not be assessed against those of us who embrace the new named variables.

 

Look, once you learned to ride a bike there's no purpose in leaving the training wheels on. Kick 'em to the side of the road!

[Cory]

Oh, another reason I don't like these CDNT vars is because I can't highlight and delete them all at once. I have to do it one at a time with confirmation. Soooo annoying. But I put in a feature request for that as well.

[Cory]

I forgot to mention a suggestion on the matter. A simply possible solution that would satisfy both the old school and new is to have a template macro much like Word has a Normal.DOT. Let me edit this template once to remove the CDNT and save it for all times sake. The old school doesn't have to do anything and I don't get a time penalty every time I create a macro.

[stevecasper]

Though I don't personally use the built-in debugger very often (my macros are generally simple enough that I can debug efficiently with text-boxes and breakpoints or pauses), I certainly see the advantage to having, at the very least, the option to turn the built-in variables off for new macros for those people who are building powerful macros and need the debugger to be clean and efficient.

 

Count my signature given.

[jsams]

Fairly early on in my exploration of the new features in MEP, I had great hopes of building a customized filter for the variables that would display all variables where (VALUE <> blank). If I created a %New Variable% or used %T1%, and it populated with something, then it would display, while all the unused T and N and D and C variables would not show.

 

I soon gave up.

 

This would certainly be a reasonable alternative to great scrolling lists of unused variables. [Was that part of your original frustration, Cory?]

 

Anyone hit on such a filter?

[Cory]

Was that part of your original frustration, Cory?

It was part but not the primary. I too got excited at the prospect of creating a filter to only show populated vars (Who cares about the rest right?) but gave up. I can't remember why now. Also I deal with some really large tables of data at times and it would be nice to turn off all or all but a few of these when troubleshooting. But I have to admit that my primary reason is this: I have decided that I believe using the old array variables when one has named variables is akin to digging a ditch with a shovel when you have a backhoe. And I tend to be tidy and delete any unused variables. So this means I have to delete 4 variables (one at a time mind you) on every new macro! So although I have plenty of good and practical reasons to back it up it's really the annoyance of; Delete, OK, Delete, OK, Delete, OK, Delete, OK.

[paul]

it's really the annoyance of; Delete, OK, Delete, OK, Delete, OK, Delete, OK.

For which it's quite clear you need to write a macro!

[stevecasper]

For which it's quite clear you need to write a macro!

LOL! As I read Cory's post I was thinking "Hmm... I think I might be able to write a short macro that would do that... and I'd be surprised if Cory hasn't already done so."

[Cory]

Well that just goes to show how petty it is that it's not worth writing a macro for! JK.

 

But seriously I gave up writing my own MEP macros a long time ago. My problem is that I write a lot of macros in different files for different clients and I tend to use the same launch pad of hot keys so it's difficult to manage them in a way that will not cause dual execution which can be disastrous. Also these macros are distributed to end users so if in the same file I need to remember to deactivate them. But now that we can have more than one file open at a time I should reconsider it. But still a lot of these client macros are not scoped so it becomes a pain. I just haven't taken the time to figure out how best to do it. How do you guys manage?

[stevecasper]

How do you guys manage?

 

I manage by mostly only writing macros for myself and maintaining the few macros my co-workers use (all still on ME3).

 

I don't suggest you drop your paying clients just to ease up your burden. Heck, if I could get paid to write macros, I'd welcome added responsibilities... and then I'd eventually find myself facing the currently incomprehensible (to me) problems that you face regularly.

 

I'm like a kid who just learned how to catch a ball watching a professional juggler tossing 7+ balls in the air and keeping them going. If he says "I wish I could do this while walking," I might think: "how hard can that be? I can toss my 1 ball in the air and walk... if you can toss 7 why can't you walk, too?"

 

Odd analogy... if it isn't clear, just ignore it and pretend I said something else.

[Rustywinger]

How do you guys manage?

This is an issue for me as well, I have some fairly large macros and many smaller "support" macros that get called up by larger ones in the old programming environment which is used by the clerk pool in an office building. Generally the macros are linking interface functions and exchanging data across a range of applications the clerks use. I began some patchwork migration on some of them after getting MEP but hit some roadblocks quickly, mainly with the clipboard copy funciton errors I was getting (reported earlier in this forum)

 

In the end I just redid the macros I use personally as the local alpha geek (how in the world did I become this?).

 

Anyway, I will probably migrate things eventually, not broke, don't fix, blah blah, but man... the data and functionality heirarchies involved in some of the already deployed macros can take me days to upload into my head so that I am working on them functionally.

 

Love MEP... gonna take awhile to fully migrate, but I think it will be worth it in the end. //just because I want to comment every line of code!!! ;-)

[terrypin]

Cory: This is pretty ancient now, but I'm curious to know its status. Did you submit your proposal formally? As I interpret it on re-reading the thread, it was: to optionally allow removal of the built-in old-style array type variables, so that new macro debugging etc wouldn't be unnecessarily cluttered. If I have that right and you did submit it then I confirm my support too.

 

--

Terry, East Grinstead, UK

[Cory]

Yes I requested it a long time ago. My intent here was to determine for ISS if other forum members were for or against my idea. [squeak squeak squeak]