mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
Joined: Aug 2004
Posts: 28
0
Ameglian cow
Offline
Ameglian cow
0
Joined: Aug 2004
Posts: 28
Code:
on *:dialog:NAME:GotFocus:1: {
  if (did($did) == Enter your nickname...) {
    did -r $dname $did
  }
}

on *:dialog:NAME:LostFocus:1: {
  if (did($did) == $null) {
    did -ra $dname $did Enter your nickname...
  }
}


Code:
on *:dialog:NAME:KeyDown:1: {
  if ($asc($key) == 32) {
    beep 1 1
    halt
  }
}

Last edited by 0nslaught; 08/04/08 06:14 AM.
Joined: Oct 2004
Posts: 8,330
Riamus2 Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
Besides that you are missing $'s in that, what is it that you're trying to show?


Invision Support
#Invision on irc.irchighway.net
Joined: Aug 2004
Posts: 28
0
Ameglian cow
Offline
Ameglian cow
0
Joined: Aug 2004
Posts: 28




Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Thank you Onslaught for the perfect illustration of the problem Khaled faces in trying to implement dialog functionality..

As much is he will implement, people will always want more control. And the UI's change faster than any one person can keep up with. 3 years ago, "auto complete" forms would not be of any expectation in interface design. The fact that it is now does not justify immediate inclusion into the program.

The true solution here isn't to make compilation list of every single dialog feature you expect to see in the next version of mIRC. This top down approach will be impossible for K to maintain or keep up with. It will result in Khaled spending all of his resources building high level widgets for every use case possibility. Is mIRC an IRC client, or is it a windowing toolkit?

No, the true solution here is to ditch the lists and work from the bottom up, not the top down.

If the dialog problem is to be solved, Khaled needs to write a low level api for the "controls" themselves. This means that a "checkbox" should be no functionally different from a "listbox"-- they are both controls. The only difference would be how each one draws and how each one redraws after interaction.

Doing this would allow anyone to modify he behaviour of any control indiscriminantly of its type. Khaled would not need to implement "autocomplete" for the edit control only to have someone ask to have it implemented for a listbox selection.

Doing this would also allow people like Onslaught who want autocompletion or other customized intefaces to implement it themselves.

Onslaught alluded to a good point here through his example of events. The real way to do this is to add low level event handlers (focus, keys, mouse clicks) coupled with low level interaction ability-- this means anything as far as being able to custom draw the control yourself, in its entirety, borders, custom text and all. This would be much like picwins are now, but instead with a direct handle to the window and GDI context.

At that point, anyone who wants a blue checkbox can go and do it, without having Khaled implement "background colours for checkboxes", "background colours for listboxes", "background colours for ....", etc.

Most of the requests in the original list could be consolidated into: "handle more events and allow custom drawing of a control"

Obviously mIRC is missing some basic controls and those would not be expected to be implemented by the user (richedit, etc.).. but these basic controls are few and could be dealt with easily at any point in time. The real issues are about the ability to truly control dialogs. Richedits (especially) are essentially useless without the low level control described above, given the amount of functionality they contain. It would be impossible to have a customized interface for all of its functionality.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Apr 2004
Posts: 759
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
---

Last edited by Mpdreamz; 10/04/08 07:55 AM.

$maybe
Joined: Apr 2004
Posts: 759
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
And you are starting to illustrate that you just shoot down new features for the heck of it.

Quote:

As much is he will implement, people will always want more control. And the UI's change faster than any one person can keep up with.


We can both go over the list and pick out the truly silly requests that would require too much work at low level for too little gain or which are relatively new to the API. Sso im not talking about those but adding an UpDown, Treeview or an ListViewEx (too name some new features) are all controls that would be used extensively.

As such, i dont see how what Onslaught suggested is any problem at all These are some pretty basic low level events that could be added withouth too much hazzle.

He didnt even mention autocompletion nor does his images show any form of autocompletion just keydown validation and ghost texts which is supported in the win32 api directly already as well and shouldn't be any hassle to add as well, although ghost texts are relatively new they could be scripted using focus events and some more control over the font and colours.

You make all the wrong assumptions here:
  • Khaled himself added dialog support
    So your question "Is mIRC an IRC client, or is it a windowing toolkit?" is completely irrelevant nor any reason to shoot down new features.
  • Khaled himself chose to make a high level script engine
    So shooting down any new features because a low level approach might be better is again irrelevant and no reason to shoot them down. Low level control is even less likely to happen.


The fact remains that there are alot of controls/events/commands that can (and perhaps should) be routed to be controled from mIRC that wouldnt take too much work. For those who want complete control over everything should look into making picwin GUI's or think twice whether mIRCScript is even the right tool for the job.


$maybe
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Quote:
And you are starting to illustrate that you just shoot down new features for the heck of it.


Wrong. I'm saying compiling lengthy lists of each individual feature is going about it the wrong way. The right way to solve the issue is to design bottom up, not top down.

I repeat. Khaled should improve dialogs and add new features. The features he should add, however, should not be a list of high level custom controls.

Quote:
Khaled himself added dialog support
So your question "Is mIRC an IRC client, or is it a windowing toolkit?" is completely irrelevant nor any reason to shoot down new features.


Khaled added dialog support, good observation. However "dialog support" is far different in scale from "a windowing toolkit". You would not expect to "do anything" with a UI made from dialog support, whereas a windowing toolkit exists for the sole purpose of complete control. This is not an assumption at all.

Quote:
Khaled himself chose to make a high level script engine
So shooting down any new features because a low level approach might be better is again irrelevant and no reason to shoot them down. Low level control is even less likely to happen.


The false assumption here is being made by you. Low level does not imply anything will be lower level than the scripting engine itself. I think you're misinterpreting what "low-level" means in the context of UI controls. A "high-level" control in this case would be a "richedit control" whereas a low-level one would be a basic text-box. In fact, the lowest level control would just be a rectangular area inside a window that could be drawn on using *high level scripting functionality*. mIRC has no support for this low level control. Adding such support would solve many problems in the list, though it risks turning mIRC into more of a "windowing toolkit" than it is meant to be (see above)-- again, low level here has nothing to do with scripting in this context.

Quote:
The fact remains that there are alot of controls/events/commands that can (and perhaps should) be routed to be controled from mIRC


I agree fully. This is exactly what I am asking for as well. The control, however, should start from a lower level. This would give people the ability to roll their own should mIRC not support something natively, without relying on DLLs. Given the ability to custom draw a control, there would no problem for me to implement the "number choice" suggestion by genius_at_work until mIRC added the control natively. I could do so in mIRCscript instead of waiting on Khaled to give me more freedom. This is what I am asking for.

Quote:
For those who want complete control over everything should look into making picwin GUI's


The difference in implementation to allow complete control in any Windows window is conceptually the same. There should be no reason why complete control is attainable in custom windows (a regular child MDI window) but not in a dialog (a regular desktop window). In fact, I believe this is one of the suggestions in the compilation list.

Quote:
or think twice whether mIRCScript is even the right tool for the job.


Much better said. But what other tool is there? DLLs are rarely a better tool for UI stuff.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Jan 2008
Posts: 22
D
Ameglian cow
Offline
Ameglian cow
D
Joined: Jan 2008
Posts: 22
Well i hope he does get round to improving dialogs and takes the request seriously i get a strong feeling that most these feature reports barley get looked at and the main focus is the bug report forum fixing some fancy $regsub identifier that returns something ambigious when used in a certain manner which may affect one in a thousand users.
Dialogs are used by everyone all the time and an update would mean alot to us users.

Joined: Oct 2004
Posts: 8,330
Riamus2 Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Oct 2004
Posts: 8,330
I think that is the exact point people are making regarding dialogs. Most people who script anything will use dialogs in at least some of their scripts. Dialogs are used all of the time and having greater control of what you can do would make just about everyone who scripts much happier. Even if they don't use a specific control, the option to use it would allow them to consider options when making a dialog that they don't have otherwise. It allows more freedom when trying to decide how to set up a dialog. The font control alone would probably be used by most people who use dialogs... even if they just use the font size part of it.

We can get into the fact that mIRC is a chat client, but the scripting engine (and dialogs are a large part of that) is perhaps the most important feature in mIRC. It is *that* which makes mIRC different from every other client out there. If we didn't have a scripting engine in mIRC, then mIRC wouldn't hold such a huge lead over all of the other clients out there. It would be just one out of many similar clients rather than something unique.


Invision Support
#Invision on irc.irchighway.net
Joined: Jan 2003
Posts: 2,523
Q
Hoopy frood
Offline
Hoopy frood
Q
Joined: Jan 2003
Posts: 2,523
Quote:
i get a strong feeling that most these feature reports barley get looked at and the main focus is the bug report forum fixing some fancy $regsub identifier that returns something ambigious when used in a certain manner which may affect one in a thousand users

That would be an unfair and uninformed feeling. If you take a look at versions.txt for example, you'll see that most fixes/additions are GUI/display-related or involve general (non-scripting) IRC-related features. Those are the priority, as you'll no doubt agree that there are more mirc users than dialog scripters.

Dialogs are indeed popular, but there are dlls (MDX, DCX) that pretty much allow you to do anything with dialogs, so I really don't see why additional dialog features are so much of a priority. Even some "fancy $regsub" fix would be more important than a new dialog feature imo, because there is no substitute for the former.


/.timerQ 1 0 echo /.timerQ 1 0 $timer(Q).com
Joined: Apr 2004
Posts: 759
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
The false assumption on your interpretation on high and low level is indeed mine.

Although such low-level control would be great to have i highly doubt its less hassle then route certain message loop events and commands from the script engine to winapi and other way around. Also adding support for a few more controls wouldnt even take that much trouble. The RichEdit as you quite rightly stated is a handful to port to a maintainable/feature rich implementation in mIRC, same why we at DCX feel the RichEdit should be redone completely as the first attempt to port exposed severe functionality drawbacks.

Some more events and controls and more control over the fonts/colours/icons will work miracles in useability and more importantly scriptability.


$maybe
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
Originally Posted By: Mpdreamz
Although such low-level control would be great to have i highly doubt its less hassle then route certain message loop events and commands from the script engine to winapi and other way around.


I think that what he's saying is that it would be less work to add low level support than to constantly add new controls and features.

Obviously one or two features/controls might be easy enough to add but where does it stop? DCX has been going on for years now.. Khaled can't really dedicate that much time to building up dialogs and neglect everything else.

That being said, I would still rather see high level support than low level, even if it's just one new control/feature/event per version!

Code:
dialog t {
  title ""
  size -1 -1 300 300
  treeview 1, 0 0 300 300, lines buttons
}


Beautiful <3

Joined: Jan 2006
Posts: 468
Fjord artisan
Offline
Fjord artisan
Joined: Jan 2006
Posts: 468
Oh, how I wish <3

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
The beauty of low level support would mean the ability to add any native high level windows control very easily, specifically things like "treeviews", "sliders", etc.

This would be because they all have the same underlying low-level interface ("add item", "select item", "set value", "redraw", "get focus", "lose focus", etc.) that merely adding the ability to create a "treeview" would nearly add support for all of its functionality.

Imagine being able to create any of these controls. With a low level interface it would be far easier to implement these all in one fell swoop.. In fact, Khaled would need not implement any of the controls at all, he would just need to expose the Windows API and messages that are passed back and forth.

The beauty of windows' api is that it's an event based system, meaning it would be extremely intuitive to convert a WINAPI message like "TVN_SELCHANGED" into:

Code:
on *:DIALOG:dname:TVN_SELCHANGED:id: {
  ; react
}


Of course, the event names themselves can be changed, but this could apply for hundreds of different events and it could all be consolidated in one single dispatching function.

There. Treeview support added.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Apr 2004
Posts: 759
M
Hoopy frood
Offline
Hoopy frood
M
Joined: Apr 2004
Posts: 759
I agree that that an open approach to WM_NOTIFY,WM_COMMAND's and CreateWindowEx would be very cool and easier that was actually exactly what i meant as well when i said:
Quote:

route certain message loop events and commands from the script engine to winapi and other way around.


smile The misconception i had was that by custom drawn you meant owner drawn which would be just as silly request as wanting control animations supported through commands in mIRC.

Last edited by Mpdreamz; 12/04/08 01:19 PM.

$maybe
Joined: Apr 2008
Posts: 1
M
Mostly harmless
Offline
Mostly harmless
M
Joined: Apr 2008
Posts: 1
Originally Posted By: Riamus2

I have done this look at this short video http://youtube.com/watch?v=wt5SjIeeFew

Joined: Nov 2006
Posts: 1,559
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
No offense; quoting the feature suggestions sticky 'Friendly reminder, forum guideline':
Quote:
(...) Improve on suggestions or show the poster why his suggestion just wouldn't work or make sense ("you can script it" is not a valuable response).

Quote:
Would it be easy to write a script for my idea?
If it's something that is very easy to do with scripts, chances are it won't be built into mIRC. (This isn't always the case, but should be considered when posting your idea.)


Now, you neither provide the code, nor would a scripted sollution supersede the value of an in-built spin bar for the scripting community smile


Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
In addition to what Horstl said, the original poster already underlined this point :
Originally Posted By: Riamus2
And, yes, DCX and other DLLs can do much of this. There is no need to point that out. These are just suggestions people have for what they'd like built into mIRC's dialog options rather than having to rely on DLLs to do it.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Apr 2003
Posts: 342
M
Fjord artisan
Offline
Fjord artisan
M
Joined: Apr 2003
Posts: 342
You ppl do realize you aren't talking about dialogs, rather UI customization. Let me be clear. Designing a well designed, intuitive interface with a lot of different objects, controls, etc, is HARD.


Beware of MeStinkBAD! He knows more than he actually does!
Page 2 of 2 1 2

Link Copied to Clipboard