Forums Feature Suggestions an update to tooltips...

the current format for $tip includes 'iconfn'

$tip(name,title,text,delay,iconfn,iconpos,alias,wid)

is there any way that it could also accept the data as used
in $input... ie:

iqwh - show the info, question, warning, and halt icons respectively.

while the icons displayed in $input are of a different size
than would be needed for $tips, having the basic icons
available via a letter (and not having to have seperate
.ico files, as i now have) for tips would be a nice
addition.

I like the idea, but since each letter of "iqwh" is a valid filename, you would need a special way to tell the difference, maybe using the iconpos value.

Great point wims, and thanks.

It would be pretty unintuitive to use iconpos since you would still be required to specify iconfn when passing in these switches.

It was just an example, you could pass $null for iconfn and use the letter in iconpos

This is exactly what would be unintuitive.

It doesn't seem that unintuitive to me, it's related to the icon after all and we can already pass $null there.
The syntax doesn't really matter anyway.

This isn't a matter of syntax, it's a matter of semantics. The syntax isn't in question, the semantics of forcing the user to pass an empty value to get to the next useful parameter is the issue. "we can already pass $null there" is easy for someone who knows the API to say. Please tell me how you would explain this to someone who has never used $tip before, and potentially doesn't know what $null is. I can't think of any way this can be documented without seeming insanely confusing to a user who doesn't know the language extremely well.

True, but in many cases, we're already passing $null in $tip, so it's not really any different. That said, I think custom icons are better than default ones anyhow.

Keep in mind it's not just because you dislike very much the semantic in place that it will prevent its usage.
I undertand your concern and I agree this is far from being the best choice but the semantic is already there everywhere in mIRC (passing $null isn't just something you do in $tip), imo it's a good enough reason to keep going with it, no matter how bad you think it is.
Your example was an extreme, you don't start using the scripting language with $tip but I wouldn't help someone with $tip knowing he doesn't know what $null is, pretty simple.

But it is. There are actually very few places in the language where $null is ever used as a parameter unless you're doing something very weird. It's mostly used in if conditions, but not command arguments. This is why it's so confusing and unintuitive.



Please don't assume to know how scripters start out. People start scripting for whatever their needs may be. Scripting something that pops up custom information triggered by an event is a perfectly valid "first script" project. Note that I did not say "never programmed before"; there are plenty of people who can program and want to do X in mIRC but aren't comfortable with the API. It would not be easy to explain this to new or knowledgable programmers.

I would say that + should be used as a prefix in iconfn to indicate that the parameter is a set of switches. There is precedent for prefixing switches with +, albeit in /commands, but it would be easier to explain.

actually this whole issue could be resolved if the icons that are internally built in mIRC (used in $input) were made available. Then anyone could just use them in $tip

Those are standard Windows icons, you can already find them in shell32

For convenience though, resembling open sourced icons could possibly be added to the 64 mircexe icons...