sumdumguy wrote:howdy. first of all, thanks for creating this fantastically useful and user friendly program!
Thanks for all the reports and suggestions. I really appreciate that! I can't promise fixes soon though, as I'm very busy with other projects and must finish them before I can give attention to PMC again.
sumdumguy wrote:the first and most important feature request (imo) would be to have an optional setting to delay all queued key/button inputs (but not 'pause commands') until a set number of milliseconds have passed since the last user interaction.
... a good open source program that could be investigated for this is touchfreeze, a program which prevents typing errors by silencing all touchpad inputs made within a certain number of miliseconds of the last keyboard keypress.
as it is, i'm generating a LOT of errors from running a long list of commands while in the midst of typing. a passable (albeit bothersome) workaround is to pause the active macros before starting to type (which kind of defeats the purpose).
I don't know, this could compromise accuracy. What kind of commands are you running in this long list?
sumdumguy wrote:some other features that would be useful are to have 'play from selected row' added to the right click menu, to have the option of preventing the program from shrinking to the taskbar when activating a macro
I don't see how these two things are related. You can already access this option from the Macro menu and from the Play button dropdown menu on the main window.
sumdumguy wrote:and to make double clicking on the taskbar icon maximize the program window (which sometimes works but usually does not for some reason EDIT: it tends to not maximize if the macro is paused).
Double clicking on the tray icon will activate your macros and, if you have the "minimize to tray" option active, it will hide the window (unless you have an empty macro open).
sumdumguy wrote:most importantly, there seems to be some kind of memory leak ... or something. from a clean boot on 64bit windows 7, after running 11 cycles of a 349 step macro with only this program and firefox running, the portable version of 4.1.1 started dropping commands left and right and applying certain commands before they are meant to be executed. the strange thing is, the behavior is not completely random; certain commands at certain places and at certain times keep getting dropped or applied, and attempting to circumvent this behavior produces other strange, unwanted behaviors instead. very odd. the strangest recurring error is when the program appears to apply an extra command that isn't in the queue list for a particular macro and it keeps doing this at exactly the same place each time. fortunately, it was near the end of the macro so i simply trimmed out the part that seemed to be giving me problems.
I've taken some measures to avoid memory leak and I can't see anything like this happening here. What commands are you using? Can you give me a sample to try to reproduce this behavior? Or maybe a video showing this happening?
sumdumguy wrote:likewise, some queued clicks end up being misplaced (unfortunately, usually at the beginning of the macro), usually ending up 1/3rd of the way down from the screen or 1/3rd of the way up instead of where they are meant to go.
Coordinates are relative to the active window by default, if you record them to a window and execute them when a different one is active it might cause misplaced clicks. The recorder adds a command to activate the window before clicking to avoid this. If that's not the case, again I'd need to be able to reproduce this error.
sumdumguy wrote:the control bar appears to be bugged. the stop button(s) don't appear to work and clicking on them somehow breaks the control bar, whereupon further button presses appear to have no effect until the program is restarted or until the macro is stopped using the right click menu on the taskbar.
I could not reproduce this here. Could you be more specific?
sumdumguy wrote:a feature request that stems from this is to have a setting to not activate the control bar at all.
There is a button in the default layout. I should put this and a "minimize to tray" in the view menu too.
sumdumguy wrote:stopping a macro after pausing will cause the activate macro button to do nothing when it is pressed, and will cause the macro to unpause when attempting to record new actions.
There does seem to be something wrong with the pause button. I'll see what I can do when I get the time.
sumdumguy wrote:if the macro recorder main window is open, the macro that is being run and looked at stops running even if no changes have been made.
This is by design. We don't want our macros messing up our project, do we? Besides there are certain routines that run on the background when the main window is active, the program would go crazy if I was to allow the macros to execute on its own window.
sumdumguy wrote:the image / pixel checker appears to be broken. i've never gotten it to work at all.
Works fine here. This is a simple button control, there's nothing special about it.
sumdumguy wrote:also, your tutorial is unclear on where the else command is supposed to go.
I do believe I said it should be inside the block.
sumdumguy wrote:in my experience, instead of checking for a particular image or pixel and then running an if else command, the program will simply apply a fairly long pause (easily 15 seconds) as it skips over these commands.
Can you post a code that behaves like this? You can open pmc files in notepad.
sumdumguy wrote:the winminimize command appears to be bugged as it exhibits totally random behavior. the exact same commands in the exact same macro will sometimes work and sometimes not, even without editing the macro. an easy workaround is to queue an alt tab, which works every time.
Well, I've tested here and it's working every time.
sumdumguy wrote:tooltip balloons for the control bar tend to not appear unless the control bar is opened through the right click menu on the windows taskbar.
The controls toolbar has a special property that allows it to be clicked but never active. Because of this the tooltips won't show when a window other then the main one is active.
sumdumguy wrote:the visual element that displays the list of queued actions tends to freeze when rapidly scrolling pgup/pgdown. an easy workaround is to reload the visual element by shrinking the program to the taskbar and reopening it. thankfully, when this happens, none of the commands are lost or corrupted.
This might happen sometimes because of the function to paint rows for loops and ifs (it's a very consuming function). If you don't mind you can disable highliting in the view menu.
sumdumguy wrote:i think this program has a memory leak or something ... the longer one goes running or creating macros, the slower the program (actually, the entire pc) becomes and the more macro recorder errors happen to appear (such as the aforementioned visual bug, commands dropping or misfiring in the wrong window), usually while pasting a command or while a macro is running. after the program crashes, computer responsiveness returns to normal (in windows 7).
This is a little hard to test, but I'll see if I can find something. Did you check the task manager to see how much memory the executable is using when this happens?
sumdumguy wrote:i've not been able to get macros exported as exes to work. likewise, i've been unsuccessful getting macros made using macrorecorder to run in autohotkey, although they do run in macro recorder.
What do you mean they don't run in autohotkey? In all my tests here it plays exactly the same.
sumdumguy wrote:thanks again for creating this awesome program! despite the bugs, it's still massively useful and i hope that it gets improved on!
You're welcome. Thanks again for all the comments, I'll work on fixing the bugs as soon as I can.