Forums Feature Suggestions New Scripts Editor Window

I have two ideas to a new Scripts Editor Window. I will try to write here, but my english is not a good thing! (lol)

1. Make the Scripts Editor a normal window, with the MAXIMIZE and MINIMIZE buttons, like all other windows.

2. Make some Syntax Highlighting for script codes. This wil make coding a lot more easy, and also, a lot more easy to learn scripting for mIRC.

What do you think about that?

I wish to suggest (again) that the internal script editor be removed from mIRC and replaced with an external script editor, and a means of communication (sendmessage) added to inform mIRC when it should reload a script and whatnot.

This would allow a basic external script editor that can be improved upon without adding significant bloat to mirc.exe, and can be replaced by independantly made open source script editors with all the bells and whistles of syntex checking/ highlighting/ dialog creating/ theming/ etc.

- Raccoon

That'd be great. Scripts could then be made interoperable between clients

The script interpreter would still be the same, and scripts would still be written in plain text. Just the editor UI would be external and expandable.

Well if the editor was open-sourced, the other clients (i.e. xchat) could possibly then incorporate the editor (or create a clone of it) albeit with a few tweaks to the identifiers (e.g. $os returns Linux not the win. ver.).

...or was that not on your line of thought?

Well, the editor has never evaluated things like $os before. It's just Notepad with added features like a {} button.

I'm just suggesting the actual editor window be removed from mIRC's innards. Instead when you press ALT+R or click the toolbar icon, it will launch mircedit.exe. An editor window will appear as it currently does, but this time you can choose to use Khaled's built-in editor, or one with more options.

The reason the internal editor would be removed is so open source editors can be equally integrated with mIRC using the same channel of communication to /reload and whatnot. I suppose this can already be done with SendMessage, but I'm not sure how completely.

I would rather see an external editor that grows to 5MB with all sorts of bells and whistles, than watch mirc.exe blimp out of control.

I think it's a good idea. But I would prefer it coming as a package together with mirc installer...

the only drawback i see here is what happens when the user replaces the editor with a buggy one or if they remove it all togethor. one solution would be to keep the internal editor but have a command /useeditor <filename> to use whatever editor you choose. In this case if the editor doesnt exist or cant be loaded you still have the default one to fall back on.

to further add to this idea (by the way i like it alot) the new editor can use the same format as dll's do (and could be written in a dll as well). It would export a function similar to the LoadDll/UnloadDll functions. The only difference in this case is if the LoadEditor function doesnt exist then the old one is used instead. This way mirc can ensure that any initialization such as the current file to load is actually sent to the editor. I would suggest (a rough starting point)

typedef struct tagLOADEDITOR
{
const char *file_to_load;
unsigned long line_num;
//some other things an editor might need to init itself
}LOADEDITOR,*LPLOADEDITOR;

BOOL LoadEditor(LPLOADEDITOR editor)
{
return TRUE;//tells mirc that everythings fine do not open its internal editor
return FALSE;//something is wrong maybe we dont handle the file type run the default editor.
}

all of this is of course just a rough draft and can definately be added to but this way mirc can ensure that an editor of some kind will be opened wether its the internal one or an external one.

mirc should also export some functions such as

void Reload(const char *scriptname);
void Unload(const char *scriptname);

etc..

of course thsoe fn's could be made to return an error num instead in the event that scriptname doesnt exist or for whatever reason mirc could not perform the action.

Why keep the internal editor if an external one would exist anyway? Looks senseless to me. If you had a buggy one, or if you didn't have one, you'd download the right one at mirc.com, or stick to Notepad and /*load. If an external editor existed, there would be no need at all to keep the internal one as mirc.exe garbage.

With the external script editor, perhaps just be able to define a hotkey to launch it, and make it take a path. Then stuff like Editplus (a proven app with all sorts of bells and whistles) can be run inplace of the standard exe.

IF the editor went bye bye it'd be great as your average mircer doesnt really script - they can get by in notepad really really easily.

I think those features you suggested that help mIRC work smoothly with external editors, could be added anyway, And mIRC could keep it's simple editor integrated, for the sake of conveniance.

Although, There are some external editors now, They can already use SendMessage and WM_MEVALUATE, to tell mIRC to reload a script.

Then someone make it happen, and stop bringing up additions to mIRC's script editor.

Tell to me the name of that external script editor you said that allready exists. I want to give it a try!

well the reason to keep mirc's editor is quite simple. Alot of scripters while proficient at what they do know little to nothing of C (or other languages to produce exe's). They may try to expieremnet with one eidtor that causes a crash etc..

Removing the editor wont actually decrease mirc's size by too much its just a template in the resource file. All of the code to load/unload scripts etc.. would have to remain anyway otherwise how would an external editor tell mirc to load a file if mirc doesnt know how to load it?

It would be a bit faster/easier to just leave it in instead of wasting time removing it khaled could just start working on supporting external ones.

Hmm yeah, you're right.

Okay, It's called mEditor.

I agree, however, in adittion (and this has nothing to do with the editor), I'd also like to see an option to compile mIRC scripts (of course, being an option, we would still be able to use plain text files as scripts),

But meh.