last change focus command messes up my macro.

[bowlesj]

Hi,

 

I have been using MacroExpress for about 3 months. I have 3 macros I wrote and the initial use is to move and size windows.However I decide to rewrite some keystroke macros that I am running in MS-Access using MacroExpress to run them instead. The initial basic write of the macro worked great at first. The key stroke commands activate a charting program called MultiCharts then execute key strokes to adjust the chart bar spacing. The idea is to initiate the macro from MS-Access using a shell command (example shown below) then once the MacroExpress commands are finished I would active MS-Access again. Okay so I put the final command in to activate MS-Access and it is executing this command before all the prior commands complete and the macro of course stops working completely. In MS-Access I can cause it to not execute the next key stroke command until the prior one completes. I would assume that MacroExpress should be as good or better than MS-Access in this regard but I do not see where I can control this. Am I missing something. I was looking for both a command specific param or a global param but I could not find anything. If I can do this then I would also be hoping there is a way to have MS-Access know when MacroExpress has finished the macro but in order to do this the MyAppID (shown in the shell command below) would need to be set and I could test it but I am not sure if this is possible either. Any ideas would be appreciated.

 

Thanks,

John

 

 

Dim MyAppID

 

{this opens the macroexpress program and the file with the macros}

MyAppID = Shell("C:\Program Files\Macro Express3\MEProc.exe /FC:\Access\MacroExpress\TradeAssociationClose.mex", vbMaximizedFocus)

 

{this is a sample of the macro call}

MyAppID = Shell("C:\Program Files\Macro Express3\MEProc.exe /ATradeAssociationClose", vbMaximizedFocus)

[bowlesj]

I guess I can not update the post. I wanted to change it to remove the idea of having MS-Access know when MacroExpress is finished. Apparently the shell command can not do this. It is too bad that MacroExpress could not process GlobalVariables. If it could do this then I could set the variable in MS-Access and have the timer look see when MacroExpress had change the variable.

[Samrae]

Does MS Access have the ability to read from the registry, from an INI file or from a regular file? Macro Express can write to these places. Another idea would be to have Macro Express write to a file in .csv format. I would bet MS Access could read a .csv file.

[bowlesj]

Hi Samrae,

 

Thanks for your response.

 

I do not think the version of MS-Access I am using can read the registry. That is an interesting question for the MS-Access forum (can any version do this). For sure MS-Access can read/write csv files (tab separated and any separator). However for the sendkey calls I am using this would be way too slow. GV transfers are amazingly fast since it is just a move statement to a specific memory area that can be accessed by all programs (special addressing outside the scope of the program itself that other programs can also address to with the GV calls). I have tested the speed of this since I use it to communicate back and forth between MS-Access and the MultiCharts program that supports the GV2.0 standard. If this ability was put in MacroExpress that would be a big selling point for the MacroExpress program since MS-Access can not position windows or size them and it would be useful if there was a way for MS-Access to do this sort of stuff by calling MacroExpress more often during the day.

 

I may be on the verge of solving the MS-Access send keys problem. It may be that some of my sendkeys calls are not being fully completed by the operating system and a command called DoEvents is the command that releases control to the operating system to complete these commands. I am also trying the Windows Refresh command and it seems that it may be clearing some memory areas in addition to just redrawing the screen. I have two MS-Access programs running. I may need to bring them both down in the afternoon after 5 hours of running to see if this will clear some memory areas. I say this since I did a test with the GV calls (Global Variables calls). MultiCharts and my two Access databases use them. If I bring any 2 down the GVs are retained in memory. However if I bring all 3 of them down the Operating system clears this memory area and I have to reset them as I do in the morning. So maybe this type of thing is happening with my sendkeys slow down problem.

 

Thanks again,

John

[bowlesj]

I forgot to mention I am not getting email notice of posts here. Maybe I need to review my profile.

[paul]

I do not think the version of MS-Access I am using can read the registry.

Really? What version of Access are you using? Are you competent in VBA?

[bowlesj]

I am using Access 97 (no time these days to learn the new vesions). I have been programming it every day since about 1995 (been programming full time for 32 years or so although I now only program it to help me with trading).. I learned it at my old programming job work place by printing about 5 feet of manual pages and reading them all then filling in some holes in my knowledge using 5 thick books I purchased. I do not remember reading that the registry can be read nor have I had the need with the apps I have developed for my own personal use (never programmed VBA for others). I will check the help. If it can do it maybe I can find a use for it.

 

Anyway, the real issue is the last command (the set focus command or appactivate command). It needs to be able to wait for the others to finish before the delay comes in. I can not see creating a long delay which is an estimate of all the commands before. If I have to do that it is just a lot easier to keep using MS-Access because the sendkeys command does have a parameter to wait for the command to complete and the delays which give control to the operating system to complete its tasks create the needed one at a time process. It may be that the delays in MS-Access need adjustment such that after 5 or so hours of constant use they do not create a backlog.

[bowlesj]

GetSetting Function

Returns a key setting value from an application's entry in the Windows registry.

 

So I guess it can. An example from the help.

 

 

 

This example first uses the SaveSetting statement to make entries in the Windows registry (or .ini file on 16-bit Windows platforms) for the application specified as appname, and then uses the GetSetting function to display one of the settings. Because the default argument is specified, some value is guaranteed to be returned. Note that section names can't be retrieved with GetSetting. Finally, the DeleteSetting statement removes all the application's entries.

 

' Variant to hold 2-dimensional array returned by GetSetting.

Dim MySettings As Variant

' Place some settings in the registry.

SaveSetting "MyApp","Startup", "Top", 75

SaveSetting "MyApp","Startup", "Left", 50

 

Debug.Print GetSetting(appname := "MyApp", section := "Startup", _

key := "Left", default := "25")

 

DeleteSetting "MyApp", "Startup"

[bowlesj]

Okay so I guess the idea is to have MS-Access write to the registry key an initial value and when MacroExpress completes have it mark that same registry entry as complete. MS-access would be waiting in a loop to detect the registry change (for a max number of loops or max time). I guess the speed would be somewhere between the GV speed and the CSV speed. I do use CSV for across machine communication but as I said it is a tiny bit slow.

 

Thanks guys, so I know how to get them to talk to each other now in a new way. But the big problem I do not have the answer for and it needs to be solved first. However, I suppose MS-Access could bring the focus back. But I will be surprised if MacroExpress can not solve this.

[bowlesj]

I can not see an edit button on this forum. Is there a way to edit a post after you have submitted it? Sometimes things are missed in the preview.

Thanks,

John

[bowlesj]

Yes an edit button would save people time since I often go back and reread stuff I have submitted a few times (even over a few days on one forum I frequent). It helps because a rewording often makes things more clear for people (or just adding something in).

[paul]

2 issues to be aware of:

- when you invoke MultiCharts from ME, then ME will probably not know when MultiCharts has finished. Assuming that the MultiCharts process terminates once finished, you have loop within ME until the MuliCharts process has been unloaded from memory

- Access is an MDI application; this makes the process of handling its windows quite complicated, and not one that ME handles well. However this should be irrelevant if you are simply reactivating the Access window

 

If you don't want to use the registry method of checking when ME has finished, you could also create a file and have Access check for its existence of absence.

[bowlesj]

Hi Paul,

 

Yes Access also does not know when all the MultiCharts windows are done. I have lots of DoEvents in a special loop that creates a delay releasing control to Windows (basically the MacroExpress Wait command I would think). It took me a long time to get the delay sizes just right so the macros would run. They seem to be espacially important when opening a menu in MultiCharts. After getting this set correctly there really is no problem with the running of the macros and their function even after the 5 or 6 hours of intense use (we are talking probably a good 300 to 600 runs (a guess) and each may have 10 sendkey commands). They still run mostly correctly. They just start to run much slower and the forms that come up in MS-Access start to do a hard to describe kind of double flash (sometimes causing a form which is acdialog to get transmitted and skipped by so quickly I can not see it). I will admit that this running slow at times does mess up the functions of the sendkeys causing for example a menu open to get skipped and unpredictable results (but in the first few hours this never happens).

 

It may be that the simplest solution is just to set up MacroExpress to restart everything (restart all the programs after I do a reboot and restart of the machine). In order to do that I need to do some programming to store and reset the Global Variables I have in memory (certainly doable). So this would give me two 4 hour sessions thus avoiding the slowdown. It is probably about the same amount of work for me as having to rewrite all the SendKey functions in ME (there are probably 20 or 30 functions I have that issue sets of sendkeys along with the AppActivate command). The advantage of the reboot is I know it would work. Rewriting in the sendkey functions in ME is an uncertain solution (an experiment). No matter the choice ME is a very useful new tool for me and I wish I was an expert in it (some day).

[bowlesj]

I did a google on Windows API and found some tutorials. I gather it can be very useful to know this language for both MS-access and I would assume for ME too. Even without having touched the C language, I have learned 11 languages in my 32 years of programming. ME is 12. windows API is 13. There is no end :-)

[paul]

I did a google on Windows API and found some tutorials. I gather it can be very useful to know this language for both MS-access and I would assume for ME too.

Uses for Windows API routines are very limited in ME, with Postmessage being the only option.

 

FYI, here's some AutoIt code to fire a macro called, in this case, Textbox. I'm sure you're able to convert this into VBA if it's of interest.

$dll = DllOpen("user32.dll")

 

$hwnd = DllCall($dll, "hwnd", "FindWindowW", "wstr", "TMainWin", "wstr", "Macro Express Player")

$hwnd = $hwnd[0]

For $i = 1 to 10

$Result = DllCall($dll, "bool", "PostMessage", "HWnd", $hwnd, "uint", 1044, "wparam", Asc(StringMid("Textbox", $i, 1)), "lparam", 0)

Next

$Result = DllCall($dll, "bool", "PostMessage", "HWnd", $hwnd, "uint", 1044, "wparam", 0, "lparam", 0)

DllClose($dll)

[paul]

Even without having touched the C language, I have learned 11 languages in my 32 years of programming. ME is 12. windows API is 13. There is no end :-)

Yes. I've also learned several languages in my 40 years of programming; I suppose I've learnt 13 or so, but believe I've become expert at perhaps only 5 or 6. I always wonder whether the relentless pressure to produce more output in less time has led to a marked decrease in quality. They used to say that if you wrote 5 lines of bug-free Cobol a day, you were doing well. I wonder what that translates into these days!

[bowlesj]

Thanks for the code Paul. I will store it in my reminder system and often later I get back to things like this.

 

Yes. I've also learned several languages in my 40 years of programming; I suppose I've learnt 13 or so, but believe I've become expert at perhaps only 5 or 6. I always wonder whether the relentless pressure to produce more output in less time has led to a marked decrease in quality. They used to say that if you wrote 5 lines of bug-free Cobol a day, you were doing well. I wonder what that translates into these days!

I started at school in assembler, cobol, rpgII. Mostly did cobol for my work but I am not sure if I was an expert. I purposely became an expert in unix shell scripting (learning all commands in other words - it seemed to fascinate me for some reason). These days all I so is VBA and MutliCharts EasyLanguage (not sure if an expert).

 

 

They used to say that if you wrote 5 lines of bug-free Cobol a day, you were doing well.

My first reaction is it seems low. The biggest thing that stood out with me the 19 years I did cobol programming was the fact that estimates were usually 1/3rd the actual. Managers don't want to hear that. They want a low estimate so upper management will buy into the project then it is a mad scramble to get it done with a good percentage of bug fixing. Debuggers are a god send. I remember the first MicroFocus Cobol debugger (that fascinated me and I became an expert in that debugger). If the other programmers had a bad bug they would come to me to help them use the debugger to find it. I will never forget one of the best programmers in the shop coming to me because she just could not figure out where this loop bug was. I set it up for her on the debugger and within 5 minutes I found it for her (she actually found it but I had to use the debugger to direct her to the location where it was occuring) (big contrast with the hours she had already spent using her standard methods).