Linda

good question

 

I have a set of about 800 macros but I think the one I'm the most proud of is a macro to analyze "speckled" (hope it's english ?) bitmaps and perform characters recognition 

Um, please, please tell me you're not using this to spam newlists/message boards that use the speckeled text authentication to filter out bots? (Sorry, it's just the only use I can think of for this at the moment).

Please clear up this possible misunderstanding by sharing what this macro is used for?

(In any case, I agree it would be some fine coding to get it to work, but still...)

Ah, here's the thread, with Floyd's solution:

http://pgmacros.com/community/index.php?showtopic=118

A while back, someone posted code about how you could simulate arrays with a trick that used the "Run Macro in Variable" command. Perhaps that is what the poster is looking for?

I'll do a quick search, and see if I can find the post.

Cool, thanks for the info.

Linda

Thanks--

I'll try setting the cache up. If that doesn't solve the issue, I'll push for the tewakme fix (although I hope that's not neccesary, since requesting the download, install, and configuring of even a tiny application on two dozen users' machines is going to be a beurocratic nightmare )

I think it is a caching issue, simply beause it's slowest the first time I run a macro, or if I come back to a macro after running several others.

Cheers.

I mean subroutine macros- macros called by the first macro using "Macro Run", not independantly invoked by the user. And they exist in the same MEX file-- is that what you mean by "in the same library"?

Hmm...

Further testing shows that the slow-downs aren't consistent. I guess It's not ALWAYS slower, but there is definitely greater variation in speed with the macros broken out.

Maybe it's not overhead from macro-calling after all?

Hi!

I'm wondering if anyone has any thoughts on optimization of ME scripts.

As I break more and more short but repetive peices out of the latest batch of legacy macros I am revising, the code is becoming clearer, but it is also taking noticably longer to run. Since these scripts are used interactively to help people with common workflows, ths is a problem. There seems to be a great deal of overhead in calling a new macro, dragging up the cost of what in other languages is good coding practice.

Is there a way I can reduce the overhead of macro-to-macro calls, so that I don't have to have gobs of repetitive code to improve preformance?

Thanks!

Sorry, I guess I wasn't very clear, was I?

Is this better:

// T1 = Break all the way out of loop? (True/False)
Variable Set String %T1% "False"
//
// Any type of "Repeat" or file-reading loop
//      will work for the outer repeat loop
Repeat with Variable using %N2%
    Repeat Start (Repeat 1 times)
         If <some condition>
               // Do some processing
               // now we want to go to the next iteration 
               //     of the %N2% loop
               Repeat Exit
         end if 
         
         // Do some other processing

         if <some other condition>
              // Do some processing
              // now we want to exit the repeat loop entirely
              Variable Set String %T1% "True"
              Repeat Exit
         end if
         if <yada yada yada>
              // Process, process, process
              // Next iteration:
              Repeat Exit
         end if

         // do some processing

         if <etc>
             // ...
         end if
    Repeat End
    //
    if Variable %T1% = "True"
          Repeat Exit
    end if
Repeat End

Hi!

If someone already has a more elegant solution for this, or if I've missed a built-in feature, please let me know .

I had been somewhat irritated by the lack of a "next iteration" function for the ME repeat loops (at least in 3.0.4.1) -- functionality that would let you skip the rest of this iteration of the loop, and begin the next iteration. I've been spoiled by it in other languages.

But, behold! It is possible to do this in ME!

Immediately inside your Repeat loop, create a second, inner repeat loop that simply says "Repeat 1 Times". Now, using "Repeat Exit" will jump you out of the inner repeat loop- and back to the beginning of the next iteration of the outer loop!

To be able to also really "Repeat Exit" the outer loop from the inner one, you can define a "Really Exit?" variable, and have code at the bottom of the outer loop check this and "Repeat Exit" if it = 1 or "true" or whatever.

Posting this in hopes that someone else will also find it useful.

I'm not clear about your use of "front end" and "back end" - and does it really matter?

No, it doesn't really matter. I was just aknowleging that I may have gone outside the scope of your question, which asked "What sort of functionality do you envisage for the VB back-end" which I see now was just refering to my use of the word-- my apologies for the confusion.

And all my questions about what needs to be installed are motivated by the fact that I don't run the show here, and I'm already stirring up enough dust by using two or three macros to do what could be done in one (because I like to seperate out clearly distinct functions if they're lengthy, even if they aren't being re-used immediately by another macro.). I think I'd better hold off a little before reccomending adding a sizable macro library and a bunch of MS .DLL's to the user-distribution process But it's definitely something to think about after another month or two, when I can find a way to reccomend it without scaring the (relatively non-technical) people doing the distribution & management of the macros.

I'm a software developer/computer geek suddenly thrown in with less technically-minded people, and it's taking us a little while to get used to each other

The usefulness of a VB server will be increased or decreased by the power and ease of use of the interface between ME and VB - i.e. how do a macro express its commands to VB without a million interactions between ME and VB. Perhaps an Ascii file of commands, data and parameters might be a good way to go - do you have any thoughts on this?

Good point, about limiting the interface between the two. I don't have any real thoughts to add- I'll admit my experience with VB is minimal (used to avoid it like the plauge, because it was such an annoying language to work with, which is why I find it so ironic that I'm pushing for access to it now -- but the right tool for the job at hand and all that, even if it's not my prefered tool ) and you certainly know more about the guts of ME than I do.

Thanks for your time!

Perl's just really pleasent for processing line-by-line text files with, because that's what it was designed for- it has lots of very nice text-processing ability. Problem is, it would need to be installed on every user's machine, and would add another point of failure, which probably isn't worth it just for my convenience. Ah, well.

So, if I hooked up with VB, I'd probably be doing a lot of text processing with it. If I could use it with the suite to get at the contents of list boxes, I'd definitely do that. And use it to make more complex forms, so I didn't have to present users with a multiple-choce single-select menu, followed by a check-box menu, followed by a prompt-for-variable. (but that's "front end" not "back end").

Accessing VB through the PGM suite- would it be possible to create an EXE of the VB functionality I created, or would VB need to be installed on every user's machine? I know I could create an .exe myself and just have ME run it, but I mean the link-in functionality provided by the PGM suite.

Ah, the disabling input- two edged sword. My fist impression was a strong positive-- it would certainly prevent some macro goof-ups. On the other hand, if a macro hung anyway, it would make getting the macro to stop rather difficult (oh, wait- "except for ctl-break". OK, that's more do-able)

Thanks!

It sounds like some program on your system may be intercepting keyboard hooks.

Try selecting "Restore Keyboard Hooks" from the "Tools" menu of ME, then try using the command-key launch again.

Floyd- tried it with several list boxes- all return blanks. Closed combo boxes return their current contents (they act like edit boxes) while open combo boxes (which I think the app treats like list boxes, or maybe custom controls) return blank.

Paul- ah, I've been lightly pushing forVB, to allow more complex user forms than ME allows, and to handle some back-end processing (I'm requesting a VB back end? Did Hades just freeze? ) and this may help me push the case a little harder. (Perl to handle the text-file processing is also on my wish-list)

With the PGM macro suite- do all the macros need to be installed, or only the relevant ones? We keep macros in several shared files used by a handful of departmens with several users on each. If I were to request a macro suite, the first question I'd get is how much more complex this will make our distribution process. (simply hiring me is straining our current process a little bit- I've recently been hired full-time to a year-term position just to write macros to streamline use of two applications I mentioned above!)

Thanks both!

Sorry, I sould have been clearer- my afterthought about combo-boxes confused the issue.

Yes, I can capture the current selection in a combo-box, it acts just like an edit-box in that regard.

My real concern was getting any information from list-boxes, which I haven't yet found a way to do- either getting the current selection or all of the possibilities would be very helpful. (being able to see all the options on a combo-box would also be helpful, but not as key as getting any info from a list box.)

Thanks!

Have you tried the Window Control commands?

Yes, but (at least for v.3.0.4.1) they return empty strings when I try to Get Control Text on list boxes or other "complex" controls.

Is there another way of accessing the contents of controls that works for List Boxes? (or Combo boxes?)

EDITED to add:

Another thing to note is that the message used to retrieve the content of something, in this case a list box, *may* be different for each application.

99% of the macros I'm dealing with are for two applications from the same suite. They just happen to be unusually complex, with muliple controls-within-tabs-within-panes-within-tabs-within-modules-etc (all the controls dynamically allocated, of course, so as to foil "get control" )

So being able to read some list boxes in one application only would be enough to make me excedingly happy

...

sound of crickets chirping

...

OK, having looked into it a little more, I'll try a more specific question then:

When when you post a message, Windows sometimes sends a return value. Is there any way to access this return value thru ME, or does the PostMessage command only allow you to post a message without seeing what the response (if any) was?

Thanks!

To set an infinite repeat I usually use "repeat until %N99%=1" where %N99% is never set or incremented (lots of other ways to do this or limit repeats).

For infinite loops, I usually use "repeat until %N1% <> %N1%", because it's then obvious even to someone unfamiliar with the code that this is never going to return true.

But like you said- many ways to do it

Hi,

ME (at least my version of it) does not allow one to access the contents of list-boxes directly. But is it possible- and has anyone done it- to access the contents somehow using the "Post Message" functionality? I'm starting to look into this now, but I figured I'd see if someone had already done it or knew it couldn't be done.

...uh, Glad we could help?

Oh! That's the peice I was somehow missing- that it's not translating it directly, but that the saving it and loading it were a crucial part of the picture. Thanks!

From the help file :

Reset Hooks

 

It is possible for other programs which are run after Macro Express to improperly install themselves into the system wide Windows keyboard and mouse hooks. This causes Macro Express to no longer be able to monitor keystrokes or mouse movements and clicks.

 

This command will reinstall the Windows keyboard and mouse hooks used by Macro Express while your macro is playing so that Macro Express will have the first look at the keystrokes and mouse movements/clicks and be able to monitor them again. 

This is much more elegant!

Floyd- does this using variables-inside-vairables only work on the newer versions of ME?

I had tried to get it to work before, and could not. When you posted a source example for it the other day (thanks!) I tried to get it to work based on that, and could not.

Am I doing something wrong, or is it the version of ME I'm using?

I tried the script you posted above, but substituted a "Text Box Display" for the "Macro Run" call. The text box displays %T1%, and comes up as (three successive runs through the loop):

<NMVAR:08:89:0:0000001:0:0000000>

<NMVAR:08:96:0:0000001:0:0000000>

<NMVAR:08:63:0:0000001:0:0000000>

i.e, it's just inserting the variable within the string, not reading the resulting string as a variable.

(As always, institutionally stuck with 3.0.4.1 for the itermediate-term future, at least)

Perhaps the "Reset Hooks" command would help? It's possible that Mozilla/Opera are hijacking the hooks (which, especially in the case of Opera's gestures, is very possible)

Perhaps the focus is in the wrong pane? It could be trying to scrol the menu bar or the URL window rather than the main window.

Does it work if you set a control (say C1) to the main window using "Get Control", then "Set Focus", and then scroll?