Forums Feature Suggestions Major Feature Suggestion

mIRC Dialogs: Dialogs are a great tool for mIRC! They allow you to create scripts with a graphical interface. They're easy to make, easy to use, and fairly fast. They are the best tools for customizing how you use your mIRC. The only problem with mIRC dialogs as of today, is how limited they really are. You can do extensive things with them, exchange great amounts of information. However, you can't customize them fully.

Well, here is the suggestion! It's a great tool called "DCX Studio" made by twig. DCX Studio is the future of mIRC Dialogs! It has hundreds; if not thousands, of new features not yet supported by mIRC. You can check it out at http://dcx.scriptsdb.org/index.htm
===================================================================
Now that I'm done "advertising", I'm going to explain a few things.

I've been using DCX for a few months now, even before I knew a thing about Dialogs. It's fairly easy to use, and has great documentation.

Now, I can't speak for twig. However, I'm sure he wouldn't mind handing over the source code to see it integrated into a release of mIRC. Not to mention, he has said it would open many more new possibilites to mIRC Dialogs if it were directly integrated into mIRC.

The main reason I'm suggestion this is so that I can continue to make the wonderful dialogs I do with DCX, and not have to make sure users have this file or that. Not to mention, as fast as they are already; it would only make them faster.

Either way, one thing I think would be great to see as a new feature in mIRC is a better dialog system. One with a "dialog generator" would be great. If you don't know exactly what I'm talking about, I'm talking about the "Visual Studio"-like dialog builder.

I really can't say much more, you'll simply have to try this thing for yourself to know what I'm talking about.

I guess, most mIRC scripters know DCX and also many use it.
However, I would rather like to see major issues fixed and general stuff done than waiting longer because of some extension for dialogs.

Also, developing tools are not a part of the programmer's job here - usually the community creates such stuff, such as "Dialog Studio" which makes it pretty easy to create new dialogs and edit old ones.

What you say is true. The other issues should be worked on first, of course. I'm just saying that it would be nice to see more dialog integration in the future. As well, I should think a dialog builder would be necessary, as I would hate to imagine taking the time to guess the coordinates of everything to make a good looking dialog.

However, at the same time; I could mention many issues I've run into that don't involve dialogs. Personally, I think sockets need to be worked on before dialogs. All I am suggesting here, is that we take what has already been made (DCX), get the source; if at all possible, and integrate it into mIRC. Rather than taking a lot of time away from fixing other issues, why not use what twig made?

However, I'm fairly novice when it comes to programming; and I'm not sure what that would take.

As already mentioned, "Dialog Studio" does that pretty well, just google for it...

And also, I doubt that it's possible to simply implement twigs code into mirc...
It would have to be rewritten I guess.

I'm not sure exactly what your suggestion is. Improving dialogs has been suggesed before.. many times, in fact. Use the search, you'll see it. If you're talking about integrating DCX into mIRC, that's also been suggested, and hasn't happened (and I doubt it will).

As for integrating twig's dialog editor. I doubt Khaled wants to maintain software for a DLL he (probably) knows nothing/very little about. Find someone in the community who wants to do this-- there are many people who can. Doesn't twig already maintain this? What's the problem with him just continuing to maintain it? Khaled already has his hands full with mIRC, and there's no one else who can maintain that but him, so I (and I'm sure you) would rather see him focus his effort where no one else can.

Frankly, there's no reason to throw open source or community projects onto Khaled, it defies the whole benefit of being an open source / community project to begin with-- better support, faster updates, delegation of resources, etc. Improving dialogs is one thing (a very complicated thing), but making Khaled support projects he didn't author is pointless. There's a reason mIRC has dlls, scripts and a community surrounding them.

IMHO, using DCX to do dialogs is a way better idea than wasting Khaled's time reinventing the wheel or even supporting a reinvented wheel for "builtin support"'s sake. I'd actually much rather see mIRC just drop native dialogs and tell people to just get DCX. That way he can actually spend his time on features that matter to *IRC* users: the long overdue unicode support, per-network user configurations, etc.

Personally I think it would be great if Khaled added dialog support slowly. Maybe one control or major enhancement to an existing control per version.

The check/radio listboxes were added in two consecutive versions and I've used them a hell of a lot.

It's so much better just being able to use native dialog scripting to using third party DLLs. It's more uniform.

While i find myself agreeing with the last paragraph

The DLL bit i see in a slightly different light. There's no reason why Khaled shouldnt include/depend on third party DLL's. In fact mIRC already does this with SSL, GIFLIB , PCRE and ZLIB. DCX could even be used as a linked library that users can update themselves by replacing it. All DCX needs is that dcx_tools become built in aliases. This would infact really help on achieving the point you make in your last paragraph.

I'm not saying i definitely see this as a decent solution, nor that i feel it something that should be done but that it's something worth a ponder.

I think the major things wich the dialogs needs are the TrackBar and the ProgressBar. At least this!

The difference is that SSL, GIF, JPEG PCRE and ZLIB are extremely stable projects with very minuscule changes from version to version. Updating those libraries is rarely necessary and generally done out of convenience or just for the sake of "being up to date". I can't remember the last time a bug in one of the linked libraries made its way into a script. The last build of the JPEG library, for example, was released in 2001.. that's 7 years with zero changes.. contrast that with DCX and I'm sure you'll find a very big difference.

DCX on the other hand may update the library to introduce large feature changes or fix many (more serious) bugs, and this would not follow into mIRC until the next version release -- we're talking 6 months to a year per version, given mIRC's release history. And then, because all the identifiers would be builtin, it would be hard/impossible to override certain ones, which would completely disable anybody from wanting to use the latest versions of what *should* be an externally supported DLL.

On the flipside of the coin, if DCX isn't being updated often enough and is *not* fixing bugs / introducing features faster than mIRC releases updates, people will simply start complaining on the mIRC forums about the "DCX BUGS!" that aren't being fixed. Khaled would then become responsible for code he didn't write and mostly knows little about, which is unhelpful both to him and the well-being of mIRC, the codebase he's MEANT to support. Or how about this... what would happen if the DCX author decided to stop working on the project sometime down the line? Who would pickup the pieces? Khaled? This can't happen to one of the above mentioned libraries, because they have huge open-source support and many hundreds of thousands of applications depend on them-- ssl/gif/jpeg/zlib aren't going anywhere.. DCX might die tomorrow. Sounds more like you're asking him to inherit more work for the sake of your inability to download a .dll file.

This was all covered the last time this exact issue was raised, I suggest Searching for the discussion and reading it through so save the need for repetition.

Comparing DCX to those resources is comparing David with Goliath, granted. I'm just putting it out there that there are other options then a DCX compiled into mIRC's source but to still be a part of mIRC.

Please don't tell me to go and search for previous discussions:
1. I took part in most of them.
2. Unlike asking for help, which people could have answered themselves by searching for the solution. A discussion is an evolving matter, and more often then not is never really settled. By saying to search for previous discussions whether repetitive or not you give off the wrong signals: what you mean is you've covered you're own arguments already which is fine but is no reason for me not to state mine as many times as i damn please.
3. When you do not even read my posts.

I could list more points why it's rude but i'll save both of us the trouble.
Lastly and totally off topic: You should really get your feet back on the ground. Making comments such as:

Snobby remarks like that only make you sound like a big jerk (i'll refrain from putting it harshly) and have no added value what so ever. Because the ability or inability to download a dll file has NOTHING to do with it, and therefor reads as a lame attempt at embarrassing the other party. This is not the first time I've seen you do it and not only to me. Even if you feel the person you're replying to is a complete nitwit you should at least have the decency to be a little respectful.

We've 'clashed' several times, disagreeing on several matters and that's perfectly fine: i love discussions but do it respectfully please.

Back on topic:

mIRC could add default support by including DCX and adding a switch to /dialog to say it's a DCX enabled dialog and pass an event handler. All this has to do is create a dialog table, open it and mark it. This behavior hasn't and will not change in DCX.

Because DCX is still the external dll it is users can decide to upgrade/downgrade as they see fit and it won't interfere with creating regular mIRC dialogs.

DCX has been steadily developed since '05 and already has seen several shifts in the main leads ClickHere started then hixxy took over then twig and now Ook and Andy and myself have been doing fixes/adding new features ever since ClickHere made it open source. Right now the Team consists of 4 people that actively participate although things have slowed down a bit since the last release. So DCX has already survived several main lead changes.

DCX could die tomorrow but even if it did mIRC would still have a really decent dialog support. You seem to forget that doing this is a nice to have for us scripters, even if it had some small bugs(and inherintly being it's software it has rather then had) it wouldn't affect the regular mIRC user.

Adding this support will also save mIRC on theoretical development time as well, granted it would implement all the feautures and the learning cure for DCX is very low indeed especially for someas as apt with WINAPI as Khaled if he ever did wanted (not needed) to fix something.

Acquiring a large new codebase doesn't have to be the big evil thing you make it out to be and the benefits could possibly be a huge time saver for Khaled.

Now as stated this is all theorizing, i'm not whiny about wanting this added am i? I'm just casting a different light over the matter. Wheter it will be added or not is irreverent.

About the first part... you're not alone with that opinion.. even if I would not publish that, we're all humans and I guess, a private message would have done the job, too.

As far as I could get it, you just propose to add DCX to mIRC as a third party application, without really implementing it into the source code...
Why don't people simply write a short script that checks for the DLL being available and, if it's not, downloads it on load?
Seriously, that's not that much code... maybe 50 lines.

Including community projects is a step too far... That makes no sense, you can't just add all features you like to the programm by default - mIRC is made for chatting, not to teach people creating dialogs properly...
The amount of people who actually use DCX in their addons is rather little..
And those people who try to use a script referring to DCX - well, they were able to get the script, how difficult can it be to download DCX after that?
I guess, thats what the "readme" idea has been made for... (or, as already mentioned, sockets.)

I don't see what good including a DLL with mIRC will do. In order to benefit from it users must have some kind of script using it, meaning they still have to download something - why not have the DLL in the download aswell? In fact they must have the DLL in the download aswell, otherwise there can be no guarantee that the version currently available to one user's mIRC will be acceptable for any given script since even if they require a specific version of mIRC there's no guarantee that the user hasn't chosen to "upgrade/downgrade as they see fit".

You obviously wouldn't check for $version but $dcx(version). The main benefit would not be saving a DLL download as most dialogs still include other external resources such as icons, that's why i kept hammering on the fact not having to download the dll is irrelevant. But to make grounds in dialog support without too much effort.

I totally agree with argv0's point:


The thought occurred to me though, why tell people to get it if your going to drop dialog support when you could already be supplying it ?

-Funnily enough having to included dcx.dll in the download is a big set back for ALOT of scripters, i've heard this numerous times (myself excluded).
-And for the general public loading dcx could be too advanced. There's a number of scripts out there that simply state get DCX.

The same could be said for SSL mIRC supports it so why not include it by default it as an option in the installer? (im not sure of the legality of this). The big difference with SSL however its an install-once kinda deal. DCX could be downloaded and 'installed' again and again and again.

Frankly i wasn't stating it should be included rather that it could without most of the cons argv0 mentioned in his first reply.

In the end the low percentage of people utilizing it simply wins over comfort, even for me, not the fact it would induce more work for khaled (which is neither true nor false) or that it could be buggy (which can't be false).

The better more elegant solution would be the standardize plugins much like FireFox and Eclipse have done. This would make installing and updating addons (and their dependencies) ALOT easier for the end user which will improve mIRC's popularity. More often then not the people who cant manage to install a mIRC script are just the people who want the MP3 player for mIRC by <someone>.

You call my statement about downloading a .dll a "snobby remark" and yet you're contradicting yourself by essentially admitting I'm right... you WOULD rather have Khaled start supporting DCX just so you dont have to download a 200kb dll file.



We wouldn't want scripters to have a setback in packaging their scripts! Let's just make Khaled agree to support DCX just so those scripters won't be hassled! While we're at it, writing the script is also a setback.. maybe Khaled should do that for them too.

When I release my dlls, I find packaging the VC2005 C Lib Redistributable to be a "setback", as well as any dependent libs I might need for the dll. You know what that's called, though? Reality.



A script shouldn't state "get DCX", it should come packaged with the dependencies it needs. That's how I would do it with DCX, or with my Ruby dll, or with my JS dll, or with my Tcl dll, or anything else I would write with an external dependency. I'm not sure of DCX's licensing issues but I'll bet there is no substantial license, so it's not a big deal. It's what a scripter is *expected* to do-- make their script work out of the box. If it means adding half a meg to your download, it's the choice you made when you decided to use the library to begin with. I'm not sure why you're treating scripters like victims here.

As for SSL, it can't be packaged for legal reasons AFAIK.

I don't think scripts need any form of "standardization". The community isn't really all that big, and anyone looking for an mp3 script by <someone> can likely find it on one of a few sites. I think you're really overexaggerating this issue, I've never seen script redistribution as big a deal as you're making it.

Im not contradicting myself:


Actually i said that by supporting DCX Khaled implements alot of dialog feature requests in a shorter period of time. Even if DCX comes to a hold with the new features it would still be up to par. This doesn't mean feature requests/bugs for dialogs will become nonexistent i'm not that disillusioned, but a great deal would be covered.



Agreed, my point was not: 'Oh a lot of scripters do not like packaging external files so it must be included' but rather 'Scripters push themselves in a victim role, when this is totally unnecessary'. I can honestly say that i didn't put those sidelines as a pro for including DCX (they would be very weak arguments, why not throw in fmod_mirc.dll etc..) but to generally state the feeling that's amongst alot of scripters how wrong they may be.

In the end I didn't mean to come off as over exaggerating, i just see missed opportunities. While I may think packaging external files is no problem, if it were easier for mIRC users to install them they would be used a lot more. One of the reasons our community isn't that big is that scripts, especially for new people can be really confusing. I'm just keen on the idea of standardized addons/plugins because it's a win win situation for both Khaled and the scripting community. Growth in popularity / usability & functionality and a larger offset 'market' respectively.

Then again i wouldn't make a big deal if neither were included if i would I'd have created new feature requests

If this were to be done there should be a "third party dlls" section or similar in the installer where one can choose to install additional features. I don't know if it's worth the hassle though.