Using "post Message" To Access List Box Contents?

[Linda]

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.

[Linda]

...

 

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!

[kevin]

The Post Message command in Macro Express does not receive a returned value.

 

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. So, even if you found the correct message to post, that message may not work for another application (or even another list box on another application).

 

Have you tried the Window Control commands?

[Linda]

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

[floyd]

Even though your original question was about the Post Message command ...

 

Whatever choice is currently displayed in a particular combo box in a particular application is not being captured by Window Controls in version 3.0.4.1? Do I understand this correctly? Does it return a blank string, or no string at all (i.e. nothing)? I would suggest taking the following steps:

1. Run the program up to the point that the combo box contains something
   
2. Launch Macro Express
   
3. Set %T1% to some value, say "AaBbCc"
   
4. Capture the combo box to %C1%
   
5. Add a Variable Get Control Text: %C1% to %T1% command
   
6. Run the macro
   

Variable Set String %T1% "AaBbCc"

Get Control %C1% (Google Search: "combo box" - : Edit)

Variable Get Control Text: %C1% to %T1%

Macro Return

Does %T1% still contain "AaBbCc" or has it been changed?

[Linda]

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.)

[floyd]

Okay Linda, take the same exact steps except capture the list box rather than the combo box. The idea is to determine if the capture is being ignored or is an ampty string being returned.

[paul]

I doubt you'll get anywhere using PostMessage - its implementation in Macro express is barely documented, is not supported by Insight, and is really not very useful. I spent some time experimenting with it, and came up with 2 uses, one of which is of no use anyway <g>!

 

The useless one - I was able to bold and centre text within a ME dialogue box.

 

The useful one is built in to our PGM library. I have written a full-blown server in VB6, which allows a macro to do the following:

- specify a maximum amount of time to process the request

- unload the VB process after a specified amount of time, or not at all

- receive a signal from VB when the process is complete

So far we use this only for returning a number raised to some arbitrary power, e.g. 2 to the power of 8. Joe did attempt this in ME alone, but it proved too difficult, whereas in VB6, of course, it's literally a single statement.

 

This environment could easily be extended to allow for array processing, or indeed any user-written functionality at all since I have created a structure to allow the addition of user code (but we've not yet published that capability).

 

In your case, it might well be possible to develop a facility to return the contents of list boxes or combo boxes. There might have to be some sort of initialization processs, so that in Macro design mode you could instruct the server which listbox to use (or perhaps this could equally well be done at run time?). Perhaps you could flesh out your requirements somewhat so that I can think about this some more.

[Linda]

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!

[paul]

With the PGM macro suite- do all the macros need to be installed, or only the relevant ones?

In our documentation we show exactly which macros are needed as a core set. I don't have our Help file in front of me at the moment, but I think it's no more than 20 or so macros that are needed.

 

What sort of functionality do you envisage for the VB back-end (which is essentially what out VB server is)?

 

And I don't really see why you'd need Perl as well (speaking expertly with an almost complete ignorance of Perl <g>). Text processing in VB can be very fast indeed (not by doing things like strA = strA & "new string", but rather by using byte arrays).

 

Also (again not yet implemented) I've found a way of disabling any keyboard or mouse input (except for Ctrl-Break) while a macro is running (again by using VB with a couple of API calls).This would be very useful when running macros that are sensitive to which window currently has the focus.

[Linda]

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!

[paul]

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").

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

On the one hand, we're using VB to carry out some processing, e.g. string manipulation, and return the results to ME.

OTOH, we're using VB to solicit some input and return the results to ME.

What am I missing here?

 

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?

 

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.

You know, there's no such thing as a pure standalone .exe program from VB, or even from C++ for that matter as far as I know. Both require a runtime library - and we distribute the VB one together with PGM library.

[Linda]

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!