Forums Feature Suggestions mIRC Exported API

While i completly agree that the mapped file was a huge improvement for mIRC dll's i woudl like to see mIRC export some API calls to make life even easier.

First doing this wouldnt be a very large load on khaled to add, all that would be needed is a few new functions that talk to the mIRC parser in the way them apped file does already and a .def file.... not to much work ive done it before.

Second i woudl suggest at first the essentials so lets say while this can already be done with the mapped file maybe two exported commands that are the equivalent of MEVAULATE and MCOMMAND so like two exported fns called DoCommand and DoAlias the dll can GetProcAddress and use to talk directly to mIRC without use of a mapped file. I am sure i will here many many comments saying THIS IS RETARDED... etc and so forth since it can already be done... but its better.. trust me.

Third the major thing that could be added though optional would be EXTREAMLY nice is like several helper api functions such as GetWindowStructure where u could get several values of a @windows struct or something assuming kahled would publish the pertants to the struct he uses to hold @windows in the help file like he does for the LoadDll structure. Some may say security risk since dlls dont need all the things in the struct of a @window and that it woudl be a lot of trouble for khaled to change his structs; however, he really doesnt even have to. Lets say theres a GetWindowStruct and SetWindowStruct. lets say kaheld publishs a struct that has some information a user could use in a dll. if a dll calls GetWindowStruct then khaled would simply copy from his internal window's information to a new struct, then send it out and the user woudl have to call SetWindowStruct where the function would validate certain members and take action accordingly depending on what needs to be done.

This whole process works EXACTLY like LoadDll and UnloadDll just that mIRC has the functions and the dll uses
SOME_TYPE_OF_FN)GetProcAddress(hInst,"SomeFnName")
then has the ability to call that function calls them if need be so it really isnt anything EXTREAMLY complex to add until you get into stuff pertaining to $cid and such.

Other objects could be exported like a channel or nicklist object the options are basically limitless. I understand that would be a lot to do an i really dont expect any of it to ever be done just food for thought though i would like to see the redundant but useful exported DoCommands and DoEvaulation or something since those are easy. Down the road though i would lvoe to see like a mEvents object that is exported and has like a setCallback Function so you could doo stuff like

mEvents event;
event.setCallBack("SomeFnIntheDll");

void SomeFnIntheDll(int Event, LPARAM lpExtraInfo)
{
switch(Event)
{
case M_JOIN:
blah blah
break;
case M_PART:
blah blah
break;
// etc
}
}

it is important to note that the dll could not alter a script running via its call back which is why it is a void function this way a dll cant halt script processing via its callback which would be stupid and very abused, with this approach the dll can only know whats going on and act when needed to say add stuff to a custom nicklist like in nicklust3 etc.

also since were on the subject of stuff that will never happen how about adding a safe subclass routine so dlls can subclass windows and dont haveta worry about being unloaded and screwing up other dlls messages thus crashing mIRC that woul dbe EXTREAMLY needed and i would especially love to say just see that. lord knows it would fix a lot of issues with dlls.

I seriously doubt any of this will ever be added ever i can always dream though (:

PS: let the flaming and general disagreement among the masses commence