Forums Feature Suggestions /dialog and its "associates" complete rebuild

It is hideous.


I've just spend the last two days trying to get a dialog to dock and run smoothly with ktools.dll and mIRC's dialog system, and I've simply given up trying. It's just really hideous (I did actually succeed, but the code was hideous, and I got to a certain point, and gave up, due to the extreme complexity of the code, and the task).

The hardest thing about dialogs, is that they aren't dockable.

So could this be put in? But if it is, please try and make it so that we can switch seamlessly between windows, and have it change accordingly. Don't forget to be able to use $snicks (yes, it works, but I've only ever had success with getting it to work with a whois command, and I know I've tried my hardest to make it loop through and do multiple bans, but it just won't.). Perhaps even being able to "tie" the docked window to the active channel name, so we can actually use $chan, or $window($active) whilst a dialog is open and running (I know I'd love this, I'm sick of setting global and local vars till the cows come home, and I'm sick of the dirty code I've got lying around doing a job half arsed).

I can only imagine that this would require a complete rebuild of the graphical engine, and wouldn't be available in the next version, but hey, Longhorn is around the corner, so perhaps we might see some changes then. I can only hope.


I'd also like to see the addition of true multi column listboxes, and being able to deselect an item in a listbox by clicking in the whitespace of the listbox.

So, here the fun begins.

*neophyte dons the asbestos suit just in case of flameage

umm, i use ktools and my docking "code" isn't "hideous" at all:
alias switchbar.dock { dll $ktools.dll DockWindow $dialog(switchbar).hwnd > left }

while i too would like to see mirc support multi column listboxes, mdx does a perfectly acceptable job of this for now.

Perhaps I should clarify further.


Actually docking the dialog was pretty easy (I had no issues with that).


Rather, my issue lies with dialogs not being able to be "tagged" to windows, ie, you can attach a specific dialog to a window, and you are able to use code like $chan, $active, $snicks etc (within the on dialog events, and yes, I know you can work them in with on init, and when you create the dialog, but actually being able to do it while the dialog is running, and on click events, would be bloody terrific), without having to resort to creating variables and so forth.

This is my issue.

u can refill it with all the nicks using a loop
alias filllist {
%sn = 1
did -ra $dname 1 $nick($chan($active),%sn,a)
%sn = 2
while ( $nick($chan($active),%sn,a) != $null ) {
did -a $dname 1 $nick($chan($active),%sn,a)
inc %sn
}
}

may not apply perfectly to your need but im sure u can tweak it a bit .. and on certain events u cant then refresh your list of nicks from a channel . hope this gives u any insight into what your looking for

I'm not going to post the code I used for this, but I've done that several times.

The issue is, it's a NASTY method to do something that we should be able to have specified as an option in a dialog.

I very much would like to be able to "attach" a dialog to a channel, and when the active channel window changes, the dialog automatically knows what window its attached to.

you keep referring to how 'nasty' your code is, but for the life of me, i can't imagine why. as in _d3m0n_'s post, simply setting the chan name to a variable and then having the dialog reference that variable should work sufficiently well. after all, the main difference is that you'd be referncing a %variable instead of an $identifier. also, if you wanted to change the channel/whatever this dialog should be 'attached' to, you simply change the %variable value.

i can say with almost certainty that what you are trying to do is not nearly as hard as you are making it.

Even setting variables won't work in certain circumstances. I've tried it from as many different methods as I could possibly think of, and none of it worked effeciently.


I've been successful in getting it to work. The problem lies in how nasty the code is to make it work.

This is why I'd like to see a complete rebuild.

the problem isnt in it needing a complete rebuild .... the problem lies in your code. your code needs a complete rebuild. i mean if i can get it to work then anyone should be able to. i am definatly not a programer ... scripting in mirc isnt even more than a yr old to me

My "code" doesn't need a rebuild. I've gone through it so many times to eliminate as much redundancy as I possibly could, and so forth. The issue lies in the fact that dialogs in mIRC suck. And they are very poorly done.

Blaming someone else - the last resort of a desperate scripter. BTW my dialogs created with mIRC are great.

Best. Dialogs. Ever.

well i seem to have no problem creating dialogs and making them work ..... i have only been working with mirc since i swtched my OS to winXp Pro since pirch doesnt fully work on it correctly. im learning a completely new way to make things work and really im wondering why i took so long to start using mirc..... i find it difficult to beleive anyone could think making dialogs in mirc are hard to understand. im definatly not a programmer or even a real scripter by any standards. i would have to suggest that if i can make mine work with np, that anyone would be able too. Im going to stand behind the belief that your troubles are in your code and not in how the dialogs work. A simple reading of the helpfile explained things to me pretty efficiantly to make mine all work. Any questions i did have were more than answered thru this forum easily. If your having trouble with your code maybe pasting your method here would allow another to show u how it needs to work rather than u going only on the assumptions your coming to.

You guys have completly missed my point. I have no problems creating dialogs.

I have problems with actually trying to get certain events working within dialogs (heck, I've been trying for the last month to get some things working). I've never, repeat, never, had an issue creating dialogs. And I've always had success in doing what I want to do with dialogs. That is, up until I started to try and manipulate certain channel events. Some work, others just simply won't.

That is why I would like to see a rebuild of the dialog system to allow for complete manipulation of the channel, and nicklist, as well as the other outlined suggestions.

what is it your trying to do that u cant seem to do? maybe your method of trying to do it is whats the issue? im not saying ur incapable of it ... im just saying the events are there ..... uve simply got to use them correctly to accomplish it. ive not come acrossed anythign i cant seem to get to go into a dialog recently... when i first started yes ..... with alot of help from here (this forum) ive found out several tricks and tips to making thinsg work. complaining the support isnt there is pointless unless u give an example of your script u cannot get working. Thats the only way i could see khaled even taking the time to redo any of these things your asking for .. is if u can give a specific circumstance

i understand what ur problem is, stuff like cant use $chan
or $nick or those kinda of identifers in a dialog.

now i can think of 1 or 2 easy ways around most of these things that was mentioned earlier that u didnt read it right maybe not sure now it wont work for all of these but for example,

set %mydialog.var #channel
do dialog stuff
then u can use stuff like $chan(%mydialog.var,theinfo,u,want)
or %mydialog.var bamaboy
$nick(%mydialog.var,nickstuffuwanted)

now i understand this isnt what u want to do but current its the only way u can do anything near what u want the main problem being $chan for example is only filled on certain events, now yes u could attach a dialog to a channel but then ud accomplish the same as setting a var to that channel name and useing $chan(%var,stuff), its a shame this cant be implemented but it would be just a little hard to do

I've never complained that support from this forum was lacking.

I've been running several different "attempts" at getting $snicks to run within my dialog, and I've only ever managed to get it to work with a WHOIS event.


There are lots more (I can't remember which ones, but will find out) events of a similar nature that simply won't run. Even when variables are set (I've been there, done it a billion times). Heck, even trying to use $gettok, and signals failed.

All I'm really asking for, is the ability to have a dialog "tagged" to a window (or group of), and be intelligent enough to automatically enable the use of identifiers such as $chan etc, without having to code for it.

I can only imagine that this would require a rebuild of the dialog engine. So whilst at it, why not build in multi column listboxes, etc.

multi column listboxes are already available thru use of MDX ... granted it would be nice if mirc where to add somethign liek this ..... but as for all your other affore mentioned problems ... i asked for code so someone could show u what your missing ..... as most of what your attempting can be done pretty easily ... its all in the method. why wont u just post a scrpit your having trouble with so it can be looked at?

What is the problem with storing the data you want to be able to work with in hidden/not visible edit/list boxes?
This is a common need; it's also not at all difficult.

If you use this, you'll be limited to what $snicks and $chan returned only when you called the dialog. You won't be able refresh the data from inside the ON DIALOG event, even calling aliases, signals or whatever, never again.

Then, if you can't refresh your custom $snicks list, what's the point of using it? If you change the active channel, your script will completely fail, unless if you access it from another separate block of code and that's what I think neophyte calls a "hideous" solution.

Please test what you suggested carefully and confirm what I'm saying yourself. I added the event and modified your 'bleh' alias, just to prove my point - but it's still the same thing you posted, as you see:

Test it:

• join a channel, select some nicks;
• type /bleh;
• move your mouse inside the dialog, click it, do whatever you want with it - your aliases will always return $null;
• close the dialog;
• type /bleh, move your mouse away from the dialog;
• type /not_an_ondialog_event - your aliases will work.

Well, I tested it here in a plain mIRC. 6.03.

-edit-
We already know that it wouldn't work this way, but I showed it just to explain what I think it's neophyte's situation. Well, if it's not, it's still a hideous situation. I'll be glad if you find any way to refresh any custom $snicks/$chan/whatever that isn't messy. I can't think of any.

-edit 2-
Ok, for $chan you could just put "if ($active ischan) { %$chan = $active }" in the refresh alias, since $active works inside ON DIALOG events... and then use %$chan and stuff.
But should we stay here refreshing variables before any small piece of code in a dialog event that needs them? It would be much better if we didn't need to fix mIRC's job, anyway. (Maybe this isn't it's job, but it would help a lot and we're on the suggestions board)

Why should I be shocked when you completely missed the point of my post? After reading how you changed my code, I am not at all surprised that yours fails.

You altered my /bleh alias and are upset when it fails. In my version of /bleh, I instantiate the dialog "in the active $chan" where I have selected some nicks and thus have access to $snicks and $chan. Then, after the dialog is created and initialized, control returns to my alias which is still running in $chan where $snicks is still working just fine. Thus, it still has access to those identifiers and can load the hidden controls with data that $blehchan and $blehsnick can return.

You introduced a lot of errors into the code and then blamed me because it did not work. I changed the names here since I already have bleh stuff. The following code follows the active channel and its snicks. Note that this is certainly not at all complex code but does reflect what it is I want it to do. If you cannot read it, I will comment it to show what each line does and why it's there.
/frog

Sorry, maybe this will be confusing, because while I was typing this post I found out that $chan and $snicks might be bugged, so this ended up not well organized.

I didn't miss anything, *you* missed *my* point.
Your alias does the job that you wanted it to do, but it has nothing to do with the problem I've showed, which is: there is something wrong with $chan and $snicks. You can't access them directly from an ON DIALOG event and you can't reproduce anything like them in this situation in a clean(IMO*) way. But the very problem is why you can't access them. After all, you can access $active. $chan is not really needed, using the same $active. $snicks sometimes is.. and you can't reproduce it.. you can't use it properly even with a timer - I'll explain this later.
Your code doesn't reproduce anything like these identifiers. It's not able to refresh that data, that's all. Then it doesn't do what's wanted.

* I'm basing "clean" in my opinion because we're talking about scripting, not about a general feature.

IMO, A clean way is: if I want to use $my_snicks, then I'll make it refresh *once* to make sure I'm getting them from the active channel and then use it.
To make $my_snicks, I don't necessarily need to base it on a dialog list or stuff like that. I don't know why did you make your alias different than what $snicks is, but anyway. $snicks was never *necessary*, it just turns life easier, with no scripted loops.
But I know that since my custom '$chan' alias could just use $active after a simple check, I could simply loop with $snick($my_chan,N) to get my nicks and group them separated by commas. But is this really a clean way to *reproduce $snicks*? If I want to use $snicks, it means I don't want a loop. I want to have access to something like it (no loops) from an ON DIALOG event somehow.

You should understand that, first of all, what I really want isn't a scripted solution, since I can handle that - I am interested, though, in any clean way to script it, and that's why I asked for it and modified yours anyway. I didn't come here to leave with a script, I already have mine for ages. I came here to suggest something that I think that should be built-in so everyone can stop tricking mIRC's behaviour, which doesn't seem to make sense to me. Why should everyone figure out they must use timers, or loops, or $active checking, then discover that timers fail with them, when $snicks and $chan and any other identifier like these could just work in any situation instead, just like $active does?

Back to your first code, I don't think I need to explain what I did with it in details, step by step.. of course I knew I changed it's behaviour, taking off the calls to $chan and $snicks from the 'bleh' alias and putting them into the ON DIALOG event. I wanted to do that to show here that you can't refresh data in that way. But I tested your code before modifying any functionality, so please don't imply I just picked it, "introduced a lot of errors into the code" and then "blamed" you. I didn't blame anyone. No one should be "shocked".
Your second code uses a loop, which breaks the purpose of trying to access $snicks, and your snicks alias isn't the same thing anyway. I hope you see my point.

Now, about the probable bug..
I'm not sure if this is a bug, but I believe it is.. but it's not with /timer, it's with these 2 identifiers. It seems they're associated only with the active window when they're called. This isn't a new issue, because the same thing happens on 5.91, except that $snicks and $chan, instead of returning $null, simply halt the script.
Join 2 channels. Select your nick on one and another nick on the other one.
Go to the 1st channel, then type /timer 1 3 echo -a $active $chan $snicks, then switch to the 2nd one. Only $active will return the 2nd one, $chan and $snicks seem to be evaluated before that and return based on the 1st.
Type //window -a $chan(1) | echo 3 -a $active $snicks | window -a $chan(2) | echo 4 -a $active $snicks. $active will be fine, but both $snicks are the same in both channels. The identifier seems always based on the channel where you typed that in.

This enforces my suggestion to review them, I think. Or maybe, if it's really a bug, I should post this in the right place. Maybe $chan should only be used in channel-related events, as this seems to be the same mechanism that lets you use it in an ON JOIN/PART/etc event regardless of what channel is the active one, but I don't think this applies or should apply to $snicks. Plus, I thought that this behaviour was made by the event in question, not by the identifiers itselves..

-edit-
Forgot to say that I've checked the Bug Reports webboard before talking about this here.