Forums Feature Suggestions 2 suggested addons

not sure if someone else has suggested these but i think scripting would greatly benefit with the addon of registry editing and maybe built-in xml parsing.

Registry editing? Through mIRC scripting? Can you possibly imagine just how many virii THAT would bring about? Not to mention system crashes.

file editing also creates the same problem. erase files just using the write command. same difference.

i just find that ini files are totally out of date (although i like them, they are obsolete). restrictions could always be put on the command like you can't delete system values and stuff like that. always a way to make things safe.

I suggested registry manipulation not too long ago, but the idea got shot to pieces. I still think it should be implemented! If you're interested, you can view the thread here.

I still don't see why this cannot be implemented and be disabled by default. If it was disabled by default, what harm could it cause? None!

imo, if you want it there is a snipplet hanging on the forum that allows u to achieve just this. Although as Hammer pointed out its hard enough keeping mirc virii and trojans off peoples computer without them having the ability straight from mirc to add to their startup list.

first off, sorry, i didn't see your post. secondly, it could be implemented by only operating in say a mIRC path in the registry. make it so you can create, edit, whatever values in there and only within that area (minus any mirc set values if any).

Ex:

HKEY_LM/Software/mIRC/<user can play in here only>

my previous suggestion fixes all problems of virii and other things people would be paranoid about.

With that limitation, it's not such a bad idea, but it's basically just another data storage area, albeit a more permanent one. I would imagine that the scripts that would use it would also abuse it, not to mention overwrite each others settings.

if you really want to edit your registry why not download registry.dll? this allows you to change your existing registry,delete registry and write registry,but also keep the risk lower than actually having mirc use registry manipulation.

reet: not so much paranoid as cautious and looking out for the "every day unexperienced user"

Hammer: I do agree, but whos to stop variables from being "written over". I mean with a limitation i don't see it being harmful. You can reassign the shell or make a command startup from a mirc key

EDIT:
Phenix, i already stated that with the snipplet. There is a snipplet about that uses the com objects to connect to the registry and allow manipulations.

i do realize that the COM thing is possible but i was just thinking it would be easier to make it a built-in thing. i'm sure it will work it's way in eventually but who knows when is the question. i also hear ya on the overwriting values thing too.

what about the XML parsing thing, nobody has said anything about that yet??

If you use persistent variables (/set %varname value), that's always a distinct possibility. None of my scripts store data in Variables (except possibly during development or while a section of the script is in progress). One way you can avoid that is to use an .ini for your $script and store your data inside the same file as the script itself. When you unload the file, you unload the data; when you reload the script, the data is still there, already loaded as well. Or you can store all your script data in a hash table that your script loads on START from a file with an odd extension.

If you used a single section of the registry to hold script data, you'd be sharing that section with every other script, so the same thing applies there as would apply to persistent variables.

I personally prefer the .mrc extension and not the ini extention so the holding values in the same script is pretty much kaput. The ability to cut and past code without having to go into the mirc editor is a much preferred method than dealing with the ini's nX=Line info.

Anyways, i don't use globals either, and use ini files seperate from the script itself but i mean why not a reistry value that shares the name of your scripts. If you have remote01.mrc what's wrong with
HKEY_LM\software\mirc\remote01 >:D

Either way you look at it there we be pros and cons, likes and dislikes, but its really only up to one person. "The Man"

haha well put King. "The Man" does have the last say no matter what we type here. We will just have to wait and see what is done. Hey, maybe he will implement it using the registry.dll and just make alias commands to access it.

storing data in the registery is definately faster than an ini file. also you can set subkeys to whatever value you like so overwriting is less of an issue however hash tables is probably just as fast as reg writes etc.. and they already exist so i dont see a need for built in registery options.

However if it were added hopefully you can have at least read access to othe keys for things like checking system info etc..

Alot can be used for bad /bwrite /write /remove etc.. this would just be one more thing that can be used that way. Ultimately i dont see it as mirc's responsibility to combat the idiots who would use the bad. I can also see the scores of posts about "mirc screwed my system up" etc.. Its a heads you win tails i loose situation.

As for XML parsing, my scripting partner made a DLL for that

XML DLL

About XML parsing I'll say the same thing I said about it last time it came up. XML is the spawn of Satan. However, XML acts like a cancer and has spread through the internet like a disease. Do to the fact that so many protocols are now using XML, it would be a great advantage if mIRC could parse XML. This would allow mIRC to parse files used by many programs, i.e. MS Office 2003 will use XML based files, so mIRC will be able to read Word documents for example. Also some internet protocols are using XML so it would be beneficial to socket coders as well. In short, I'd love to see XML die, but thats not gonna happen, so we should accept it, use it, and integrate it where ever it is appropriate.

hey ClickHere, i have downloaded that DLL and it is a good partial implementation of the protocol. It's kinda 0dd to use but once you get it, it's not too bad. The problem is that you can't just pull one value out or search the values and return matching ones. Another big problem is that you can't edit values (or save them with ease). If i am wrong then please give me some code on how to add, edit, remove values from an XML file.

To parse XML, use COM to connect to the Microsoft.XMLDOM object. This allows you to parse it with Microsoft Internet Explorer's built-in XML parser.