Macros on the fly: Idea for post 7/4 MacroQuest release
Posted: Wed Jul 03, 2002 6:51 pm
Ok -- this is something I thought of today after realizing that the new EQ UI will have the potential for MUCH more text entered on one line. I hope that it makes sense.
New command: /createmacro <filename> <template filename>
New command: /writemacro append <code...>
New command: /writemacro delete <#>
New command: /writemacro list <#/all>
New command: /appendmacro <code...>
New command: /closemacro <filename>
New command: /deletemacro <filename>
/createmacro creates a new file under the macros directory that is an exact copy of the template filename given. The template would only allow for a template "header" per se, since the macro itself would be appended to the file. However, this would allow for you to make an auctionroutines.mac file ..and then have an auction template file that contained "#include routines.mac" and "#include auctionroutines.mac' ..and any other routines you wished to have.
/writemacro would simply be the writing of the macro. '/writemacro append' would append a line of code to the file. '/writemacro delete' would delete the last line of code in the current file being written. '/writemacro list <#/all>' would either list the last NUMBER of lines entered (ie, '/writemacro list 5' would show the last 5 lines of the current file -- or 'all' would show the entire file being written. WARNING: There would have to be a check as not to flood the standard output with text and cause problems (is this a problem in EQ?).
/closemacro would simply close the file. This command would not work unless a /createmacro command had been given.
/deletemacro would delete the macro file. (Would delete any macro file, for that matter).
------------------------------------------------------
Of course, the usefulness of this concept is quite limited in scope; however, it would allow for you to create 'auction' macros on the fly instead of dealing with EQ's stupid hotbuttons. It might also allow for macros to dynamically create NEW macros on the fly.
I would offer to write the code myself; however, I am much more familiar with Borland Builder than VC++. But, if the developers are bogged down I could certainly look into it :)
New command: /createmacro <filename> <template filename>
New command: /writemacro append <code...>
New command: /writemacro delete <#>
New command: /writemacro list <#/all>
New command: /appendmacro <code...>
New command: /closemacro <filename>
New command: /deletemacro <filename>
/createmacro creates a new file under the macros directory that is an exact copy of the template filename given. The template would only allow for a template "header" per se, since the macro itself would be appended to the file. However, this would allow for you to make an auctionroutines.mac file ..and then have an auction template file that contained "#include routines.mac" and "#include auctionroutines.mac' ..and any other routines you wished to have.
/writemacro would simply be the writing of the macro. '/writemacro append' would append a line of code to the file. '/writemacro delete' would delete the last line of code in the current file being written. '/writemacro list <#/all>' would either list the last NUMBER of lines entered (ie, '/writemacro list 5' would show the last 5 lines of the current file -- or 'all' would show the entire file being written. WARNING: There would have to be a check as not to flood the standard output with text and cause problems (is this a problem in EQ?).
/closemacro would simply close the file. This command would not work unless a /createmacro command had been given.
/deletemacro would delete the macro file. (Would delete any macro file, for that matter).
------------------------------------------------------
Of course, the usefulness of this concept is quite limited in scope; however, it would allow for you to create 'auction' macros on the fly instead of dealing with EQ's stupid hotbuttons. It might also allow for macros to dynamically create NEW macros on the fly.
I would offer to write the code myself; however, I am much more familiar with Borland Builder than VC++. But, if the developers are bogged down I could certainly look into it :)
