Please Disable Ad-Block To View This Website.

If you block ads, this site can not survive!

Ads are very minimal for registered users. If you don't have an account please register now!

DOWNLOAD
 Full Scripts
 Addons
 Snippets
 DLLs
 MTS Themes
 Tutorials
 Misc.
 File Queue
 Download mIRC
INTERACT
 Screenshots
 Challenge
 Top Downloads
 Submit Form
 Forums

SEARCH
Site Search

FRIENDS
Link to us!
PhotoShelf

Home | Comments:
Average Rating:   9.6   DCX - Dialog Control eXtension v1.4.0 by ClickHeRe
Description:
DLL that extends the functions of mIRC dialogs.

Submitted Review Author's Updates
Review
This is *the* DLL for making GUI's (Graphical User Interface, aka dialogs). There's 30 controls available (listed below), each with excellent documentation on how to use them. DCX opens a whole new world to dialog makers (assuming you haven't used something similar before). If you feel mIRC dialogs lacks something, this is definately the DLL for you.

MDX by DragonZap is also a DLL to extend the dialog controls, but as of DCX, MDX is now outdated. The documenation of this DLL has a seperate section where the two DLL's are compared. It clearly proves that this is the number one DLL for dialogs.

The controls which DCX supports are the following:
Progressbar, TreeView, ListView, Toolbar, Statusbar, ComboEx, Trackbar, Rebar, RichEdit, ColorCombo, Button, IP Address, UpDown, WebControl, Calendar, Line, Box, Radio, Check, Edit, Scroll, Image, List, Link, Text, Divider, Panel, Tab, @Window, Dialog.

DCX also introduces a Cell Layout Algorithm, which is explained like this:

Quote: "The Cell Layout Algorithm is a dynamic autosizing algorithm aimed at making child controls of dialogs or container windows fully resizeable with a set of predefined rules. The rules are encapsulated in a container-like objects called cells. People with knowledge of HTML table structures will recognize the type of operations at stake. The types of cells are enumerated below with their caracteristics." End quote.

To prevent this review from getting excessively long, I'll finish by saying that this is the best DLL ever known to mIRC dialogs, and I really admire ClickHeRe for the massive amount of work he has put into DCX. The mIRC scripting community is most grateful.

Excellent job ClickHeRe!

Reviewed by myggan
Dec 25th, 2007: - Version 1.4.0


- See index for complete list of changes

Enjoy

Thanks to twig and Ook for the continued development of the project, you rock!
Screenshot:

Comments:

  Mode:    Create New Post

contr0lOct 7, 2011 3:02AM
Rating:     10Dcx is awesome, now just add a webcam control for FaceTime on irc. go go go ! lol

PoseidonOct 23, 2008 7:36AM
Rating:     9checker, I would use /xdid -x <dname> <id> +s

-x sets Borderstyle
+s sets Static edge border
^^

Text edited by author on Oct 23, 2008 @ 7:37AM


checkerJun 23, 2008 8:44AM
1.How to give the panel control a border like shown in the help file?




2.How to dock a @window into a dialog WITHOUT removing the titlebar?

yoz1kMar 19, 2008 7:45PM
Hey Hey ClickHere! this is the best ever DLL i'v ever used!! but could you please edit it, so it would be possible, to put RUSSIAN letters in the Status Bar? (maybe not only therem but thats the only thing i've tested..) please.. :) would be very thankfull!

Infernal_DemonJan 3, 2008 11:41AM
Can anyone please tell me where to find the source code of this dll???

twigboyJan 31, 2008 8:25PM
http://dcx.scriptsdb.org/forum/showthread.php?tid=235

whatrevolutionDec 29, 2007 11:40AM
Rating:     7In-advance apology for being a buzz-kill. :(

xDock is broken in 1.4.0 , or perhaps someone can show me how I broke it:

; Place and manipulate a custom sidepanel/listbox on windows, via dcx.dll.

alias listbox {
  var %listbox.target, %listbox.win, %popup, %reset, $&
    %width 

  set -n %listbox.target $1
  if (%listbox.target == -reset) {
    set -n %listbox.target $2
    set -n %reset 1
  }
  if (!%listbox.target) && ($active) {
    set -n %listbox.target $ifmatch
  }

  if ($window(%listbox.target).type) && ($v1 == custom) {
    set -n %listbox.win $+(%listbox.target,.listbox)
  }
  elseif ($window(%listbox.target).type) && ($numtok($v1,32) == 1) {
    set -n %listbox.win $+(@,%listbox.target,.listbox)
  }
  else {
    set -n %listbox.win $+(@,$remove(%listbox.target,$chr(32)),.listbox)
  }

  if (%listbox.target) && (%listbox.win) {

    set -n %width $calc( 20 * $width(X,$qt($window(%listbox.target).font),$window(%listbox.target).fontsize) )

    if (%reset) {
      if ($window(%listbox.win)) {
        close %listbox.win
      }
    }

    if (!$window(%listbox.win)) {
      window -hl +dsL %listbox.win -1 -1 %width 100 
      e -s xdock -c $window(%listbox.win).hwnd +v $window(%listbox.target).hwnd
      xdock -c $window(%listbox.win).hwnd +v $window(%listbox.target).hwnd
      window %listbox.win 0 26 140 $calc($window(%listbox.target).dh -26)
      window -a %listbox.win
    }

  }

}

menu @*.listbox {

  $iif($window($active).w >= $calc(20* $width(X,$qt($window($remove($mid($active,2,$len($active)),.listbox)).font),$window($remove($mid($active,2,$len($active)),.listbox)).fontsize)),Hide,Show):/listbox.toggle
  .-
  Cancel:/noop
  .-
  Reset:/listbox -reset $remove($mid($active,2,$len($active)),.listbox)
  .-

}

alias listbox.toggle {
  var %listbox.win, %minimum, %parent
  set -n %listbox.win $1
  set -n %minimum 4
  if (!%listbox.win) && (*.listbox iswm $active) {
    set -n %listbox.win $active
  }
  if (!%listbox.win) {
    if ($window($active).type) && ($v1 == custom) {
      set -n %listbox.win $+($active,.listbox)
    }
    elseif ($window($active).type) && ($numtok($v1,32) == 1) {
      set -n %listbox.win $+(@,$active,.listbox)
    }
    else {
      set -n %listbox.win $+(@,$remove($active,$chr(32)),.listbox)
    }
  }
  if (%listbox.win) {

    set -n %parent $remove($mid(%listbox.win,2,$len(%listbox.win)),.listbox)

    if ($window(%listbox.win).w > %minimum) {
      xdock -r $window(%listbox.win).hwnd + %minimum 0
      window -h %listbox.win
    }
    else {
      set -n %width $calc( 20 * $width(X,$qt($window(%parent).font),$window(%parent).fontsize) )
      window -a %listbox.win 0 26 140 $calc($window(%parent).dh -26)
    }
  }
}

dialog listbox.toolbar {
  title "Listbox Toolbar"
  size -1 -1 1 1
  option pixels
  ; menu "File", 1000
}
ON *:DIALOG:listbox.toolbar:*:*: {

  if ( $devent == init ) {
    dcx Mark $dname dcx_event

    xdialog -b $dname +s
    .timer 1 0 xdock -c $dialog($dname).hwnd +h $window($active).hwnd

    ; rebar acting as top toolbar
    xdialog -c $dname 1 rebar 10 10 400 400 varheight nodivider dblclktoggle
    xdid -w $dname 1 + 113 $shell
    xdid -w $dname 1 + 112 $shell
    ;xdid -q $dname 1 1

    ; Toolbar in the rebar
    xdid -a $dname 1 -1 +c 0 23 220 0 $rgb(255,0,0) Toolbar $chr(9) 2 toolbar 0 0 0 0 list flat tooltips nodivider
    xdid -l $dname 2 16
    xdid -w $dname 2 +n 112 $shell
    xdid -w $dname 2 +d 113 $shell
    xdid -w $dname 2 +h 114 $shell
    xdid -a $dname 2 0 +ac 0 1 $rgb(255,0,0) Button 1 $chr(9) Tooltip
    xdid -a $dname 2 0 + 0 0 0 -
    xdid -a $dname 2 0 +ac 0 0 $rgb(0,0,255) Button 2 $chr(9) Tooltip
    xdid -a $dname 2 0 + 0 0 0 -
    xdid -a $dname 2 0 +ac 0 1 -1 $chr(9) Tooltip
    xdid -m $dname 2 1

    .timer 1 0 xdialog -l $dname update
  }
}

So, what we have there, is incomplete prototype code which works for dcx.dll v1.3.7
Dock the toolbar to a window, /dialog -m listbox.toolbar listbox.toolbar
The /xdock is on a timer, as the new dcxdoc suggests.
Dock the custom listbox with /listbox
Reset the listbox with /listbox -reset

In v1.3.7, these two would dock together easily; one unaccounted for bug being window resizing and the listbox being too large afterward.
In v1.4.0, after the first docking of *anything*, the destination window is now unrecognizable to /xdock.

D_ERROR /xdock (Unable to find destination Window)

That error is thrown for all /xdock -c, destined toward that same window, until the destination window is reset, giving it a new HWND.

Did I do that?

PS: Merry Christmas to you, too. _o_O/

Text edited by author on Dec 29, 2007 @ 4:49PM


^Vampire^Dec 25, 2007 1:28PM
Rating:     10Wow, version 1.4.0 is finally OFFICIALLY released?
Hurrah!

Foi_MalDec 3, 2007 4:37PM
In toolbar, the command "/xdid -c [DNAME] [ID] [N] [+FLAGS] [COLOR]" (This command lets you change the Nth toolbar button ...), dont change the color if [N] = 1 (Dont color first button here), fix plis ;D

Foi_MalDec 6, 2007 6:37AM
quote:
Foi_Mal said:

In toolbar, the command "/xdid -c [DNAME] [ID] [N] [+FLAGS] [COLOR]" (This command lets you change the Nth toolbar button ...), dont change the color if [N] = 1 (Dont color first button here), fix plis ;D
If is toolbar, bug if [N] = 1
If is one toolbar in rebar, bug in all [N]

YochaiMay 31, 2007 2:48PM
Hey,
I've just started using dcx, and it seems that there's a little efficiency bug somewhere.
I'm using RichEdit in a dilaog, and I have a loop that copies text from a window or a file to the RichEdit.
I'm using:

xdialog -c $dname 27 richedit 10 10 420 250 multi vsbar hsbar
xdid -a $1 27 %line $crlf
and a loop that loops through the window and throws the text to the dialog after some changes.

Thing is, I've discovered that it slows down exponantialy. I mean, the more text there is in the RichEdit, the slower it becomes to add lines.
I echoed a few $ticks values so you can see what I mean: (it may be slowed down a bit cause i use whilefix so it won't crash. but that shouldn't make that difference.)

10 lines: 797 ticks
20 lines: 3547 ticks
40 lines: 18235 ticks
80 lines: 82656 ticks

when I watch the open dialog adding lines, you can actually see that when there are more and more lines, the interval between the added lines gets longer. until you wait like a second or 2 until the next line is added.

Text edited by author on May 31, 2007 @ 2:51PM


STINGJun 1, 2007 4:34AM
Does this problem persist with the latest development build?
http://dcx.scriptsdb.org/forum/showthread.php?tid=688
If yes, I would file a bug report: http://dcx.scriptsdb.org/bug/

Text edited by author on Jun 1, 2007 @ 4:36AM


HydragenJun 1, 2007 7:59AM
i don't know if this will help but:

/xdid -t
This command lets you load the contents of a file directly in the richedit.
Syntax: 	
/xdid -t [DNAME] [ID] [FILENAME]
Example: 	
/xdid -t dcx 4 C:\mIRC\blah.txt


YochaiJun 1, 2007 8:01AM
Nope, tried that first, but it takes about the same time.. hard to tell because it freezes mirc.
It's something to do with the way the dll handles the richedit altogether ( I think )

ClickHeReJun 1, 2007 10:22AM
Richedit is sick and needs a major overhaul in the way it draws the colored text based on the mIRC codes.

It's ok for very short text length usually used to show previews of message lines/themes (which was why I added it) but it isn't suited for very long text or a "word" editor.

The overhaul is on the list of things to do.

TCopFeb 24, 2007 3:36AM
MDX user here, converting some stuff to DCX.
Pardon me if I've overlooked this in my search of the tutorials, docs, and posts out there, but...

Is there a way to force multiple tab panels to parent a single child? For example, suppose I want to have a single text area, a single progress bar and a single listview appear across multiple panels -- the parameters/usage of these children would be changed via script while the user was in the various panels, so I don't really NEED 6 separate controls created, just 3. No, the number of superfluous code lines isn't huge, but I'm just curious how it might be done with the fewest lines possible.

I tried the following example methods, which resulted in errors (spaces added for clarity):

xdialog -c $dname 1 tab 6 5 305 350 tabstop notheme

xdid -a $dname 1 0 0 Sample Panel 1 $chr(9) 2 panel 4 22 267 249
xdid -a $dname 1 0 0 Sample Panel 2 $chr(9) 3 panel 4 22 267 249
xdid -a $dname 1 0 0 Sample Panel 3 $chr(9) 4 panel 4 22 267 249

xdid -c $dname 2,3,4 5 text 10 275 160 35 (also tried spaces instead of commas)
xdid -t $dname 5 sample text


and:


xdialog -c $dname 1 tab 6 5 305 350 tabstop notheme

xdid -a $dname 1 0 0 Sample Panel 1 $chr(9) 2 panel 4 22 267 249
xdid -c $dname 2 5 text 10 275 160 35

xdid -a $dname 1 0 0 Sample Panel 2 $chr(9) 3 panel 4 22 267 249
xdid -c $dname 3 5 text 10 275 160 35

xdid -a $dname 1 0 0 Sample Panel 3 $chr(9) 4 panel 4 22 267 249
xdid -c $dname 4 5 text 10 275 160 35

xdid -t $dname 5 sample text

Text edited by author on Feb 24, 2007 @ 4:06AM


ClickHeReFeb 26, 2007 9:03AM
No it isn't possible to do that and integrating this could be possible (submit to bug tracker as a request for enhancement) though some thought would need to be made on how to achieve this.

ClickHeReSep 18, 2006 8:02AM
There should be a new version coming soon that will enhance most of the stuff.

You can already test it by going to the forums and getting version 1.3.6dev10

http://dcx.scriptsdb.org/forum

You can also report your problems, findings or anything at that thread.

The docs for the dev version can be found at http://dcx.scriptsdb.org/dev

As soon as the version is deemed ironed out and stable, it will be updated here.

FoLKeN^Sep 30, 2006 11:57PM
could you fix the problem with the browser control at mirc 6.2 ??

ClickHeReOct 1, 2006 9:31AM
as far as it goes, there is no problem with the web control on mIRC 6.2 in DCX.

if you find something report it to the bug tracker/forums

FoLKeN^Oct 1, 2006 6:15PM
there was a problem both in nHTMLn 2.9x and at DCX, in mIRC 6.2, you may not notice it

if you attach a browser to a dialog control, then left click/right click inside it, then mIRC will freeze up

if you attach a browser (using nHTMLn) to a @window, everything works perfectly

STINGOct 2, 2006 1:13PM
Is there any reason to still use nhtmln above the web control?

FoLKeN^Oct 2, 2006 4:02PM
nHTMLn still lets you attach a browser to a #channel, query or @window, which i'm not sure if DCX does

and if someone wants to script something that will only use a web browser, nHTMLn is the best option over DCX as it is only 10 KB instead of 300+ KB which DCX is

by the way, my comment is not meant to sound competitive at all

STINGOct 3, 2006 1:34AM
My post was only ment out of curiosity, since i also used nhtmln and I thought it was bugged since 6.2?
With DCX 1.3.6 you can dock dialogs to windows, including web controls.

OokMP3Oct 11, 2006 4:34AM
This bug was fixed by handling the WM_MOUSEACTIVATE message.

FoLKeN^Oct 12, 2006 6:57PM
it didn't seem to fix it for me

could you provide me the solution code ?

TRTOct 13, 2006 8:47AM
yes, with 1.3.6 the web control works again
maybe folken, you could have a look at the source of dcx and apply the same patch for nhtml? :/

FoLKeN^Oct 11, 2006 8:56AM
is there any special reason why you don't include the source code anymore ?

i thought ms.org was an open source community

MpdreamzOct 11, 2006 9:23AM
Its because the SVN is publicly available here
:)

Text edited by author on Oct 11, 2006 @ 9:24AM


ClickHeReOct 12, 2006 10:53PM
source code is too big to fit in the allocated space with the docs and DLL itself

And since its completely open and available by SVN, people serious about getting it can do it easily.

Al1May 24, 2006 4:07PM
Rating:     10i got a problem with the new released version of dll (1.3.1)
my addon was working fine with the old version, but after using the new version with the same commands, it will crashes mIRC.
it happens on a simple alias, witch use $xdid identifier on a ComboEx control to retvire (text) .... $xdid(<dialog>,<id>,<N>).text

FX100Sep 1, 2006 2:06PM
yeah. I got the same problem as Al1.

ClickHeReSep 2, 2006 8:56AM
This version is a little outdated.

I'm waiting for the next stable release to update it everywhere.

You can get the latest on here : http://dcx.scriptsdb.org/archive.htm

or look into the forum for the latest dev version 1.3.6dev4

Al1Sep 3, 2006 11:05PM
i got that problem solved
the reason was:
/xdid -c for ComboEx will shoot the 'sclick event' and i had a /xdid -c right in the sclick event, so again & again.... , that time i was usin mIRC 6.17

but now with mIRC 6.2 after i do a single-click on Comboex control, mIRC crashes again.

anyway, i appreciate all the hard work for such a GREAT project.
keep it up ClickHeRe ;)

ClickHeReSep 4, 2006 6:57AM
that bug is being looked after.

If you get the 1.3.6dev7 version from the forums you can test it and give feedback.

fiestyAug 30, 2006 12:47AM
whoops my posts were for DCX Studio.. sorry
moderators please delete my posts.

fiestyAug 30, 2006 12:45AM
thanks hixxy
also it adds x to all did & dialog comands (ie: xdid or xdialog) why?
also status window errors for every id /xdid invalid ID : 2 (dialog : test)

ive searched everywhere & still havent found a dialog creator that can load & edit premade dialogs, anyone know of any?

fiestyAug 29, 2006 11:21PM
eerrr wen u load a premade dialog from another script, it only loads the table background. it doesnt load the text, cells, boxes or anything u have already made.
is that the way it's supposed to be?

hixxyAug 29, 2006 11:33PM
Yes. mIRC uses a completely different method to DCX and the two aren't compatible together.

FaLgoR_May 17, 2006 3:56PM
Rating:     10I can't belive there are people that think MDX is easier than DCX! DCX is easier and better, congrats ClickHere. So bad you won't develop it anymore :(

shadowofthenightMay 14, 2006 11:36AM
well i can see a lot of work has been put into this by clickhere and i usually like you're dlls. This looks impressive but im sticking with mdx, it takes more coding to add something with dcx than mdx and its a lot easier to use mdx than this. i've been at it for about 2 hours and i still haven't got the treeview added the way i want it. Never took me as long to do this at first with mdx. I'll keep plugging away with this dll but from wat i seen of coding a dialog in dcx. mdx is shorter and easier to work with , sorry clickhere :(

hixxyMay 14, 2006 11:43AM
MDX is shorter and easier to work with because it's not as good. It also means you can use something like dialog studio and have a rough idea of what the dialog will look like once you've SetControlMDXd the dialog.

DCX is much easier and better once you get the hang of it. The Cell Layout Algorithm alone is enough reason to choose DCX.

shadowofthenightMay 14, 2006 12:05PM
just cause it has cell layout algorithm doesn't make dcx better than mdx. a dll should be easy to use, dcx isn't . mdx has and always will be easy to simply add a control style. As for saying mdx isn't as good, mdx has and always been more and sufficent for people styleing there dialogs in past. just cause dcx is a new dll, that doesn't change that mdx is still more and sufficent to style you're dialogs with.

with dcx you have to learn how to code a new dialog style, with mdx you didn't. it attached on to mircs normal dialog coding. dcx doesn't. dlls should attach on to present features in mirc, not require you to learn a whole new coding style.

i have nothing against clickhere or the dll. its good that it provides something differnet in mirc. As mirc scripting has needed something new for awhile. but it pisses me off that all of a sudden people are saying due to this release that mdx isn't good enough to style you're dialogs with. this release doesn't change that mdx is a great dll.

hixxyMay 14, 2006 1:10PM
quote:
shadowofthenight said:

just cause it has cell layout algorithm doesn't make dcx better than mdx.
In my opinion, it does. Ever tried resizing a dialog and having everything align nicely using MDX? It's a pain.
quote:
shadowofthenight said:

a dll should be easy to use, dcx isn't .
Yes it is. I find dcx much easier to work with, because of the mIRCish aliases included with the dll. It also has better documentation than MDX. Your comment was totally subjective and shouldn't be used as a reason why MDX is better than DCX.
quote:
shadowofthenight said:

As for saying mdx isn't as good, mdx has and always been more and sufficent for people styleing there dialogs in past.
Yeah, right. If I had a quid for every shortcoming I'd seen people complain about I'd be a rich man.
quote:
shadowofthenight said:

just cause dcx is a new dll, that doesn't change that mdx is still more and sufficent to style you're dialogs with.
See above.
quote:
shadowofthenight said:

with dcx you have to learn how to code a new dialog style, with mdx you didn't. it attached on to mircs normal dialog coding. dcx doesn't. dlls should attach on to present features in mirc, not require you to learn a whole new coding style.
The MDX way is terribly inefficient. It uses two controls for each control (the original mIRC control and the control MDX adds itself). This isn't a good idea.

Dlls don't require you to learn a whole new coding style either, everything is done through a mIRC command/identifer; /dll / $dll
quote:
shadowofthenight said:

i have nothing against clickhere or the dll. its good that it provides something differnet in mirc. As mirc scripting has needed something new for awhile. but it pisses me off that all of a sudden people are saying due to this release that mdx isn't good enough to style you're dialogs with. this release doesn't change that mdx is a great dll.
MDX is a great dll, just not great enough. It's inefficient, it doesn't have anywhere near as many features, it's not in development any longer, the documentation isn't great, etc. DCX is better in every way.

Text edited by author on May 14, 2006 @ 1:12PM


shadowofthenightMay 14, 2006 2:40PM
quote:
hixxy said:

In my opinion, it does. Ever tried resizing a dialog and having everything align nicely using MDX? It's a pain.
entitled to you're opinion but i've never had a prob with this before
quote:
hixxy said:

Yes it is. I find dcx much easier to work with, because of the mIRCish aliases included with the dll. It also has better documentation than MDX. Your comment was totally subjective and shouldn't be used as a reason why MDX is better than DCX.
Just cause you find it easy to work with, doesn't mean someone with less experience with mirc scripting will find it easy. My comment wasn't subjective, its a fact i believe which you obviouslly disagree with. The commands may be mircish aliases as you put it but you still have to learn them and the switches that go with them. With mdx, you have to do this as well but it attaches on to normal mirc dialog controls. new scripters or not so advanced scripter, will find this easier to learn than dcx, as there already familiar with these controls.

DCX is a good dll, theres a lot to it, you can do a lot with it. But it will take a good bit of time to learn dcx due to this, not everyone will have the time to put into learning it all. If this is the case for someone, then mdx is the better option. As theres not as much to it and is quick to pick up and learn.

As for documentation, there both good but there always going be a need for tutorials for anything released for mirc.
quote:
hixxy said:

Yeah, right. If I had a quid for every shortcoming I'd seen people complain about I'd be a rich man.
Theres always going be comments about people having problems with any mirc dll, mirc addon or mirc script. it's part of mirc scripting, not everyone is capable of figureing things out and use sites like these, to post comments in hope to get an answer. To use this as a reason for dcx being better than mdx is false.
quote:
hixxy said:

The MDX way is terribly inefficient. It uses two controls for each control (the original mIRC control and the control MDX adds itself). This isn't a good idea.

Dlls don't require you to learn a whole new coding style either, everything is done through a mIRC command/identifer; /dll / $dll
so the xdialog and its switches and xdid and its switches are all normal mirc commands that people don't need to learn before using dcx then? the diffenrt controls and how you add them to a dialog with dcx doesn't need to be learned? how to actually make you're dialog functional by using xdid instead of did doesn't need to be learned?
quote:
hixxy said:

MDX is a great dll, just not great enough. It's inefficient, it doesn't have anywhere near as many features, it's not in development any longer, the documentation isn't great, etc. DCX is better in every way.
yet again i say mdx isn't suddely inefficient just cause dcx.dll has been released. As you said mdx is great, it does what its meant to provide. just cause dcx provides more features doesn't make it better. Theres the learning the new coding for people to be taken into consideration to, with dcx it will take longer to learn due to this. so if someone has a lot of time on there hands to learn dcx, then sure go with dcx. Clickhere dll's have always been great and done what they meant to well but if you don;t have a lot of time to spare. Then mdx.dll is the better choice, as you will learn it quickly, it has been efficient to style dialogs and been used by many scriptors for years to do this.

this is why i say mdx is better than dcx, it's a lot easier and quicker to learn mdx than dcx for any scriptor, whether they are a new or advanced scriptor.

Text edited by author on May 14, 2006 @ 2:44PM


hixxyMay 14, 2006 3:00PM
quote:
shadowofthenight said:

entitled to you're opinion but i've never had a prob with this before
Using a million $calcs is annoying as hell.
quote:
shadowofthenight said:

Just cause you find it easy to work with, doesn't mean someone with less experience with mirc scripting will find it easy. My comment wasn't subjective, its a fact i believe which you obviouslly disagree with. The commands may be mircish aliases as you put it but you still have to learn them and the switches that go with them. With mdx, you have to do this as well but it attaches on to normal mirc dialog controls. new scripters or not so advanced scripter, will find this easier to learn than dcx, as there already familiar with these controls.

DCX is a good dll, theres a lot to it, you can do a lot with it. But it will take a good bit of time to learn dcx due to this, not everyone will have the time to put into learning it all. If this is the case for someone, then mdx is the better option. As theres not as much to it and is quick to pick up and learn.

As for documentation, there both good but there always going be a need for tutorials for anything released for mirc.
Not subjective? You're kidding me, right? Of course it's subjective. It cannot possibly be a fact that DCX is harder to learn than MDX. Jeez <_<

Good documentation would prevent the need for tutorials. Tutorials are normally written to make up for the crappy documentation.
quote:
shadowofthenight said:

Theres always going be comments about people having problems with any mirc dll, mirc addon or mirc script. it's part of mirc scripting, not everyone is capable of figureing things out and use sites like these, to post comments in hope to get an answer. To use this as a reason for dcx being better than mdx is false.
Umm, I wasn't talking about people having trouble using the dll, I was talking about people complaining about the lack of features MDX has. There's plenty around. Try looking.
quote:
shadowofthenight said:

so the xdialog and its switches and xdid and its switches are all normal mirc commands that people don't need to learn before using dcx then? the diffenrt controls and how you add them to a dialog with dcx doesn't need to be learned? how to actually make you're dialog functional by using xdid instead of did doesn't need to be learned?
You do with MDX too. The +flags, indent, icon and other stuff for /did that MDX uses have nothing to do with mIRC. In fact, the only difference is that there's no 'x' in /did.
quote:
shadowofthenight said:

just cause dcx provides more features doesn't make it better.
It has almost everything MDX has AND lots more though. So it is of course better.
quote:
shadowofthenight said:

Theres the learning the new coding for people to be taken into consideration to, with dcx it will take longer to learn due to this.
Subjective.
quote:
shadowofthenight said:

as you will learn it quickly, it has been efficient to style dialogs and been used by many scriptors for years to do this.
Subjective.
quote:
shadowofthenight said:

this is why i say mdx is better than dcx, it's a lot easier and quicker to learn mdx than dcx for any scriptor, whether they are a new or advanced scriptor.
Yet another subjective comment. :rolleyes:

Text edited by author on May 14, 2006 @ 3:01PM


shadowofthenightMay 14, 2006 3:52PM
well theres no point in replying, you're always going say "subjective" "rolls eyes" , just cause you think its better than mdx and find dcx easier. doesn't make it so . i could go on but i just be repeating my so called subjective opionion im entitled to.

[AFX]May 14, 2006 5:20PM
Why use something that has less features, outdated, and sloppy? If I still scripted, I would be using DCX, it just seems more logical that way. You only find it hard because you have been stuck in the MDX limbo and you find it hard to accept something that is completley new, offers more features, better methods. You aren't the only one who is stuck, many scripters are. I agree with hixxy on all of his replies, and I can tell you (and many other people probably would too) using $calc to resize a dialog is slow, and utilizes CPU usage, depending on how you are resizing.

shadowofthenightMay 14, 2006 5:51PM
its not that im stuck on mdx AFX, im actually using DCX as i do like it and wanna learn it. i'm just saying , this dcx.dll doesn't make mdx a bad .dll and thats what people like hixxy have been putting across to people. instead of throwing dcx done peoples throats, they should accuratelly potray both .dlls for what they are. and thats, there both great .dlls , just one provides more options than the other (dcx) but if you dun have a lot of time to learn dcx, then mdx is the better option. due to it being simple and i fail to see how mdx was used by many scripters for many years but all of it sudden its sloopy and not good enough. as for the $calc argument, why use mdx to resize a dialog anyway, i've always used dialog -s if i recall correctlly. been awhile since i looked.

anyway, i'm just putting a differnet perspective across and im entitled to that , everyone will make up there own minds. but seems hixxy isn't open-minded enough to realise not everyone will agree with him and find dcx easier to use.

hixxyMay 14, 2006 7:41PM
I never said MDX was a bad dll.

Let's use an analogy; dialup is still a great thing, but broadband blows it out of water.

ZachMay 14, 2006 8:58PM
I tried to learn MDX.. I never could quite get it.. it was too sloppy for my understanding and the documentation was poor.. I picked up DCX in a few hours and totally got the hang of it and thought it was so much more efficient...

I love DCX, it's truely great and I don't get why people still defend MDX it's just so... old-gen... like Windows 98 style, well really 95 style.. if we are comparing windows.

Text edited by author on May 14, 2006 @ 8:58PM


MpdreamzMay 15, 2006 4:02AM
quote:
shadowofthenight said:

as for the $calc argument, why use mdx to resize a dialog anyway, i've always used dialog -s if i recall correctlly. been awhile since i looked.
You have never truely made a dialog that resizes if you say something like this. /dialog -s is needed for both dlls it's just that DCX then takes over resizing the controls on the dialog if you use CLA. unlike MDX where once you have sized the dialog you then have the $calc all the new sizes and positions of each individual control and then use a MoveControl on each individual control as well. Do you see why CLA is such a big deal now ?
, not to mention the load the MDX method causes on your CPU.
quote:
shadowofthenight said:

they should accuratelly potray both .dlls for what they are. and thats, there both great .dlls
That's exactly what i've tried to do in the DCX vs MDX section of the documentation, i try to list all the pro's and cons objectively an accurately. It's a bit outdated however due to lack of time on my part, however since that version DCX has been developed further and bugs have been fixed so i can only see more pro's going to DCX.
quote:
shadowofthenight said:

but if you dun have a lot of time to learn dcx, then mdx is the better option. due to it being simple and i fail to see how mdx was used by many scripters for many years but all of it sudden its sloopy and not good enough.
MDX has always been sloppy, it was the best alternative because it was the only one.
Inputting commands on line 1 of controls, using pages to catch special events, having a 2nd control for each MDX one to host them VS /xdid,1 callback alias,input them directly in the init event. I really fail to comprehend how you can find the MDX way easier.
quote:
shadowofthenight said:

seems hixxy isn't open-minded enough to realise not everyone will agree with him and find dcx easier to use
I doubt this has anything to do with openmindedness on his part but rather not knowing what both dlls truely contain on your part. If you find MDX easier and better than thats your right and i wont diss you for it, but fact remains DCX is better as MDX if you look at the facts.

Text edited by author on May 15, 2006 @ 4:08AM


shadowofthenightMay 15, 2006 7:23AM
well im still saying mdx isn't suddelly sloppy just cause of the release of dcx.dll and just cause dcx provides more options , doesn't make it better. it comes down to what you want to do with you're dialogs. mdx has and always will provide what i want to do with my dialogs, as i mentioned before, i'm just given a differnet perspective to this mdx vs dcx argument which i think was wrongly portaryed. it was put out there that all of a sudden mdx is sloppy and not good enough. it's still good enough to style dialogs with but yes dcx provides more options and the cla in dcx does look cool but seems to be difficult for me to pick up and im sure others will to.

anyway everyone will prefer whatever one of the dlls and will use the one they find easier to use. which for me and im sure a few others....is mdx, so i say thats better, you's obviouslly prefer dcx and find it easier to use.

hixxyMay 15, 2006 9:22AM
Even if the extra features don't make DCX better, the way it manages control is still a huge improvement over MDX. MDX hides controls that are on mIRC dialogs, and places its own controls in the positions that mIRC's controls were. This means that for each MDX control you use, there are actually two controls on the dialog. This is a BAD way of doing things. MDX IS terribly inefficient and it was EVEN BACK WHEN DCX DIDN'T EXIST. The difference back then was, there wasn't an alternative so people put up with the bad things about it. In my opinion, MDX is still a great dll, but it is not worth using now.

If you want to be lazy and use a sloppy and cpu hogging dll just because you can't be bothered to learn how to use a better one then be my guest, but don't try and get others to do the same.

shadowofthenightMay 15, 2006 2:51PM
excuse me but didn't i already say I WAS USING DCX AND BEEN LEARNING IT SINCE FRIDAY. before decideing to be an asshole , take a look at yourself first. just cause i don't agree with you doesn't mean im being lazy or don't wish to learn dcx. If anyone is trying to get others to use a dll, then this would be you. I'm entitled to my opionion and i put it across, its been yourself that went after my orginal response cause i "dared" to disagree with you. I've been nice with my replys to you're posts but i guess i was wrong about you hixxy or tidy_trax, after all....you're just another asshole online who can't stand when someones disagrees with them.

dirtySanchezMay 15, 2006 7:13PM
Okay, reread all of your responses and think it over. You have the worst grammar I have ever seen and throughout all of your 20 posts you have consistently changed your point of view because you are being consistently proven wrong. Stop replying, youre just hurting yourself.

shadowofthenightMay 16, 2006 7:06AM
i haven't changed my mind , i still say mdx is better than dcx, thats my opionion and my point has always been, dcx doesn't suddelly make mdx a bad all or insufficent.

MpdreamzMay 16, 2006 9:10AM
DCX doesn't no, MDX itself has ALWAYS BEEN insufficient.

You say MDX isn't bad because you get done what you want done with it. That doesn't make it better as DCX.
DCX is better both end result as coding wise. The fact you like MDX more is your perfect right but label this correctly and say:
"I like to work with MDX more then i like working with DCX", but even then i have yet to hear a good reason why you'd like it better.

shadowofthenightMay 16, 2006 11:42AM
to me mdx is easier to use than dcx, that's why i think its better. which i have said in numorous posts now

as for grammer comment from sanchez, yeah my grammer is awful. Always been an achilles heel of mine :(

hixxyMay 15, 2006 8:45PM
quote:
shadowofthenight said:

anyway everyone will prefer whatever one of the dlls and will use the one they find easier to use. which for me and im sure a few others....is mdx, so i say thats better, you's obviouslly prefer dcx and find it easier to use.
Make your mind up :)

Sorry if I come across as being nasty or if I seem like I'm trying to change your opinion, I'm not. All I'm doing is arguing FOR DCX, rather than AGAINST it, like you. Oh well, I'll leave it at this. I'm sure people can decide for themselves.

TeknixMay 14, 2006 7:51PM
Rating:     10This is the greatest dll in relation to dialogs I think I've ever seen. It may take a slight while to learn, but after you learn it, its like magic in action. Wonderful dll and good job ClickHeRe.

shadowofthenightMay 13, 2006 5:25PM
This my code

ON *:DIALOG:testing:init:0: {
  echo -s $dcx( Mark, $dname dcx_event )
  xdialog -b $dname +tyzsmn
}
alias testing {  dialog -m testing testing }
dialog testing {
  title "DCX - Dialog Control Xtension Demo"
  size -1 -1 520 500
  option pixel
}

there is a way to mark the dialog as DCX without the horrible echo message right?

i tried var = $dcx(blah and i can't see nuttin in the help file for marking dialog.

ZergMay 13, 2006 5:48PM
/noop was made for this type of use.

hixxyMay 13, 2006 9:25PM
a) noop $dcx(Mark,$dname dcx_event)
b) dcx Mark $dname dcx_event

shadowofthenightMay 14, 2006 9:21AM
aahhhh took a bit of time but eventually noop command seems to have stopped the echo message. Didn't at first for some reason but all of a sudden it just stopped doing the conutnious flooding echo in status lol weird

Infernal_DemonMay 12, 2006 2:17PM
Where is the source code for this new version???

da^hypeMay 12, 2006 5:24PM
nvm

Text edited by author on May 12, 2006 @ 5:28PM


ClickHeReFeb 11, 2006 6:22AM
There is a bug related to the XPopup merger in the latest version.

It has been fixed and you can get the dev build at http://dcx.scriptsdb.org/bug which is ok.

MapsychoJan 17, 2006 3:00AM
In the help files you've put the images as "../images/image.png" which doesn't work. It shoul've been "images/image.png". Apart from that it looks like the next best thing since... mdx :P

ClickHeReJan 17, 2006 10:29AM
Initially PNG, GIF and JPG support was there for the image control using GDI+, but then problems arose on certain functionality in drawing images and other technical problems (one of them being the DLL couldn't be loaded by various configurations not having GDI+ on their system). I decided to remove it, revert to BMP only support for the moment and find a way to get the other image formats in at a later point without resolving to use GDI+.

I will revert the help file to a bmp extension.

hixxyFeb 8, 2006 8:02PM
What he means is none of the images in the help files work because you've used ../images/<image> as the path to the image when you should be using images/<image>

ClickHeReFeb 8, 2006 8:09PM
yeah it's because of the online help, just put the image directory one step lower !

contr0lFeb 3, 2006 3:32PM
quick question. can you add tabs on the fly, after the dialog has been created? if so thatd make easy to make a tabbed web browser so that each tab can be dynamically created and host a different web control for each tab. Sorry for the questions, havent had time to play with it beacause of work. Quit scripting some time ago, but witht he release of dcx , this makes room for alot of ideas. Might have to comeback and make a tabbed browser all becuase of you clickhere, damn you!

Text edited by author on Feb 3, 2006 @ 3:32PM


ClickHeReFeb 3, 2006 8:07PM
you can create any number of tabs anytime.

DCX is all about dynamic controls being created/deleted on the fly.

I would suggest you wait for the next official release, there are some bugs fixes in relation to deleting controls that will be introduced.

ClickHeReFeb 2, 2006 8:11AM
You can access the DCX Community web site at http://dcx.scriptsdb.org/forum/ and the bug tracker (feature suggestions) at http://dcx.scriptsdb.org/bug/.

D_oPsychoJan 30, 2006 8:47PM
Rating:     10Sorry if this has been posted already, (I'm too lazy to read everything else.) but are you planning on creating a DCX Studio at all? That would be *the* shiznit.

twigboyFeb 1, 2006 5:23PM
take a quick look through the screenshots section
should still be on the first page i think

contr0lJan 25, 2006 4:56AM
I'd like to first off say congrats on finishing and DAMN great job!
Ive been offline for months and come back and DCX is out.. wtf!!11!!1one one1!

Anyways, what about control sub-items? Like the progressbar inside a listview cell. are you gonna do that?

Ive been waiting on control subitems for a long time, dragonzap showed me a screeny a while back, of the newest mdx version he was working on at that time, in which he was using Custom Draw and had the progressbars in listviews, among some other new things. Even if heavily restricted, as far as what could be nested in what, thatd be one if not THE biggest feature in DCX! go go go ;)

What about SidePanels like Explorer's? With the expandable headers, custom images for (bg,headerbg, expand image etc...), and diff item types. (link, detail, image, etc...) go go go ;))

And I dont even know if this is possible, but we can all wish right? Would it be possible to, after the dialog is open cache all of the control's ids and coords, so that you could add an Auto-Resize function. So a dialog could be made to be Resizable from one dll call, instead of lines and lines of MoveControl code. Not sure on how it would work, or even if it could, seeing as how the dll wouldnt know how you wanted it to resize, Maybe they could resize relevant to other controls or something, /me shrugs. A dialog Auto Resize function would just about take the cake!

All in all a very, very great dll that should inspire some great new addons! Good Job!

Text edited by author on Jan 25, 2006 @ 4:59AM


hixxyJan 25, 2006 6:18AM
quote:
contr0l said:

Anyways, what about control sub-items? Like the progressbar inside a listview cell. are you gonna do that?
That's planned. DCX also already has some container controls; panel (basically a dialog in a dialog), divider (a control which you add a control to each size and they can be resize by a bar in the middle), group box (holds a control), rebar (like the windows taskbar) and the tab control (a control can be added to each tab.)
quote:
contr0l said:

What about SidePanels like Explorer's? With the expandable headers, custom images for (bg,headerbg, expand image etc...), and diff item types. (link, detail, image, etc...) go go go ;))
I think I remember reading on his bug tracker (also used to remember features) that this control was planned too.
quote:
contr0l said:

Would it be possible to, after the dialog is open cache all of the control's ids and coords, so that you could add an Auto-Resize function. So a dialog could be made to be Resizable from one dll call, instead of lines and lines of MoveControl code. Not sure on how it would work, or even if it could, seeing as how the dll wouldnt know how you wanted it to resize, Maybe they could resize relevant to other controls or something, /me shrugs. A dialog Auto Resize function would just about take the cake!
DCX does one better with the Cell Layout Algorithm! The CLA lets you create different things called panes and cells. Panes generally have a fixed width or height and contain cells. Cells generally take up any space not taken up by the rest of the CLA. You can also add pixel indents (spaces, as they're known in dcx) between controls.
The CLA has a fairly difficult learning curve but once you get the hang of it it's the best thing since sliced bread :)

Text edited by author on Jan 25, 2006 @ 6:18AM


ClickHeReJan 26, 2006 12:48PM
in fact the box is the same thing as a panel except it has that border + text on it that is drawn. The box wasn't like that initially, it was like windows normal box which is on the same level as the controls inside it. But people requested that the controls be "inside" (child controls basically) the box so they could ne resize with a CLA counterpart in the box (just like the panel has)

ClickHeReJan 26, 2006 8:43AM
some of the things you ask for are in the works (bear with me that this is a hobby project and not the only one in line for the little free time I have)

The taskpanel that is seen in XP is not a native Win32 API control (well there is no way to access it through API though it must be hidden somewhere in windows since they use it, but it isn't available openly) so it all means that I will have to code it from scratch. One good point of this is that this control will be available to people on older versions of windows.

Progressbars in the listview is something that I need to get done too. If the progressbars were always in the same column, this would be finsihed in 2 min, but the problem is I need to get my mind around building such things for people to insert a progressbar in any column/row at any time. Also people have been suggesting that they could embed some other controls in there like a dropdown combo for example. These things need some thought which I haven't been able to experiment lately du to many bug fixes since the official release and the inclusion of other material deemed more urgent (as well as many of the user's feature requests)

For the auto-resizing feature like hixxy mentioned, you should look at the CLA stuff. Yes it may seem hard to understand at the beginning but once you grasp the concept, then you'll never resize you dialogs with $calc stuff ever. All is done via a set of defined rules that you input once when your dialog is created (after the controls are created if you want to "capture" controls in some of the cells). Then when the dialog is resized. the algorithm automatically adjusts the sizes of the cells (and their hosted controls if any) to match the rule specifications. You can nest infinitely the number of cells into each other (using pane cells). It's similar to building a web display using tables, tr and td elements. For the next big thing since sliced bread, I don't know!!! But one thing is that DCX lets you build more complexe and feature rich dialogs than MDX could especially since the introduction of container controls mentionned by hixxy,

MpdreamzJan 26, 2006 10:52AM
Rating:     10Best .dll EVER.

Sky NetJan 12, 2006 6:31PM
still have problems with xdid -u :(
butt it select to me all the items

Text edited by author on Jan 12, 2006 @ 6:33PM


ClickHeReJan 13, 2006 6:43AM
if you have a problem post it there http://dcx.scriptsdb.org/bug section DCX DLL with full code to reproduce the problem, Internet Explorer Version and Windows Version.

DanielColterJan 11, 2006 7:01AM
Awesome. This new update is working like a charm on my computer. When the older version kept giving me error messages. Thanks for the fix. Wonderful job.

superheltenDec 18, 2005 7:32AM
Hopefully there will come a good tutorial soon. Im having difficulties understanding DCX.

XconDec 18, 2005 2:43PM
mhm. same i rather use mdx it's easy to use =\

ClickHeReDec 18, 2005 2:50PM
That's because you're "stuck" in the MDX way of doing things.

I can assure you that using DCX is much easier, given the time to actually learn how to use it properly.

Plus all the goodies that it actually includes is worth it!

Text edited by author on Dec 18, 2005 @ 2:50PM


KhroniKDec 27, 2005 5:02AM
i guess so, but i don't really want to learn a whole new dll =\

btw what do you code dcx in cause i know there is a code in c++ you can use to pack the dlls and it works fine

ClickHeReDec 27, 2005 9:23AM
Well staying on MDX will lead you to not being able to use all the new features DCX has to offer, no one will force you to use it.

As for the project I compile using VC++ 2003 (Visual Studio .NET IDE).

I also tried to use upx as a packager to compress it more, but unfortunately, people can't open the DLL like that.

KlopsJan 10, 2006 10:25PM
VC++ 2003 adds extra information that unfortunately doesnt play well with upx. thus dll's compiled with vc++ 2003 dont work after being upx'd :/

L_NicoonJan 11, 2006 1:15AM
I was using visual studio .NET before the new Dev-C++ version came out. Trust me, it's worth the switch.

ZiOxIdEDec 18, 2005 4:48PM
DCX is like 20x easier. I've made toolbars, switchbars, and statusbars both with mdx and dcx, and its definitely safe to say that DCX is easier, and its less buggy and has more features. (Right-click switchbars yay!)

EnexifJan 10, 2006 8:35PM
Original: No way to change font styles at all?

Edit: I should really learn how to read...

VERY NICE DLL. I love it..

Text edited by author on Jan 10, 2006 @ 8:37PM


gr33nyJan 10, 2006 7:40PM
Nice DLL, although I'd really like to see an option to create popups looking like the default Windows ones, even when using the classic theme.

hixxyJan 10, 2006 7:41PM
Wrong project ;o)

gr33nyJan 10, 2006 7:43PM
yeah sorry :P

KhroniKDec 28, 2005 6:19AM
how exactly are you ment to dock @windows in a dialog? the help file doesnt give much info on that.

SoultechDec 28, 2005 8:58AM
xdialog -c <dname> <id> window <x y w h> <@window>

EDIT: the @window must be opened first.

Text edited by author on Dec 28, 2005 @ 9:01AM


KhroniKDec 28, 2005 6:23PM
ty, yes i know that it must be opened it's the only thing it told

RheddDec 28, 2005 11:07PM
llooll oops worng ddlll

Text edited by author on Dec 28, 2005 @ 11:07PM


EmiZDec 21, 2005 7:33AM
It will be cool a function that returns if xp visual styles are on... so we can do some alignment in the dialog if needed... hm? :D

Somethig like $dcx(IsThemeOn) ---> [1|0]

ClickHeReDec 21, 2005 8:34AM
This will probably make it in the next official version.

EmiZDec 21, 2005 12:35PM
great!!!

EmiZDec 20, 2005 5:30AM
Click, there's a way to avoid the toolbar buttons auto-resize when they are inside a ReBar Control? it looks awful... :P

MpdreamzDec 20, 2005 6:22AM
Use the CX parameter to set a minimum size for the rebar band so they wont size to small
and toggle the toolbar item resize to off (/xdid -m dialog ID [1|0]) so they wont size to big
though it should be off by default.

EmiZDec 20, 2005 11:58AM
thanks!

ZiOxIdEDec 17, 2005 4:44PM
Awesome.

codemastr_Dec 19, 2005 1:11PM
That ip address box is the best :D

codemastr_Dec 19, 2005 1:10PM
Finnaly this will i hope open up new ideas for people. New mIRC Addons. Since mIRC kinda been dead lately. :D

sprionDec 18, 2005 8:00AM
How about a little tutorial on how to convert current MDX codes to use DCX instead? Size-wise how does the MDX dll and DCX dll compare? Oh and ClickHere good job! (hope you haven't forgotten about a BURK reading or formattable list!)

Text edited by author on Dec 18, 2005 @ 8:00AM


ClickHeReDec 18, 2005 10:01AM
I could get the size down to 80 KB with upx, but some people can't get the dll to load for an unknown reason, so I left it with maximum build compression but no upx.

People will write tutorials, I don't have time for that.

EmiZDec 19, 2005 7:03AM
Oh, c'mon, don't worry about that, it worth his size in gold... I've seen DLLs that are very very larger and do a few stupid things...

Text edited by author on Dec 19, 2005 @ 7:04AM


[Hercules]Dec 18, 2005 9:45PM
i like it - i like it alike - it's just i'm too lazy to read that damn documentation - but i will.......sooner of later

EmiZDec 18, 2005 11:42AM
at lasssttt.... I can die in peace now.... great job!

BiblioDec 18, 2005 8:47AM
1) Is this DCX 1.0 final?

2) Will there be more versions?

3) Did you finally solve the problems with tooltips?

4) What about including popups and docking dll's into DCX?

5) What about the source? What if Bush go bonkers and bombs your house?

6) Ok, *WHO* starts (at least a forum for) DCX Studio?


P.D: The documentation is great too, so people will be up to it in no time. I could not find help for making menues, though, perhaps my fault?

ClickHeReDec 18, 2005 10:10AM
This is the first official release. I wanted to release it so poeple could see it was serious and have people use it to help test, report bugs, suggest features and spread the word around. I've been working on this only project since July so you can imagine why I need a break on this.

I have other projects pending and I would like to work on these too, especially my PHP5 framework that will be used to recode all my PHP driven sites.

This is not the final version, some other versions will be published later including bugfixes, new material and suggestions made by people. the development version can still be downloaded with the latest snapshot at http://dcx.scriptsdb.org/dcx.zip. I will wait in early 2006 before restarting to work on it so people have time to adapt, find quirks, bugs and suggest features, then I will invest some time on it to add new controls and features.

I will recode Ultradock in the near futur (probably beginning of 2006) and include it in DCX with the enabling of XPopups menus in the dialogs.

The source code is available inside the package for people t have a look at it.

I got no clue on who wants to build a DCX studio, but it ain't gonna be me =]

Menus are made through mIRC's menu commands for dialogs and will be the same in the futur. I will only add XPopup syntaxe like to menus items like the Channel, Status, Menubar, etc menus from XPopups in the dialogs. I will also add some $xdialog().props to help people with dynamic menus in mIRC as you can't know if a menu ID is already used, but with the proper tools, people will be able to build dynamic popups with mIRC's popup commands for dialogs with the visual touch and icons enabled by XPopup support into DCX dialogs.

There should be documentation in some other languages as soon as the people that offered to translate will send me the stuff so I can package it in the DLL and online.

BiblioDec 18, 2005 11:35AM
quote:
ClickHeRe said:

This is the first official release. I wanted to release it so poeple could see it was serious and have people use it to help test, report bugs, suggest features and spread the word around. I've been working on this only project since July so you can imagine why I need a break on this.
Go get yourself a good dessert.
Then scratch your belly button for a while.
You surely earned it. :)
quote:
ClickHeRe said:

This is not the final version, some other versions will be published later including bugfixes, new material and suggestions made by people. the development version can still be downloaded with the latest snapshot at http://dcx.scriptsdb.org/dcx.zip.
Brilliant.
quote:
ClickHeRe said:

I got no clue on who wants to build a DCX studio, but it ain't gonna be me =].
Not you. You have some serious belly button scratching to do. :)
But perhaps others will. A forum would be good, I believe. Anyone?

Thank you, an excellent answer. :)

SectorDec 18, 2005 8:10AM
I can't wait to get the exams over with and examine the source, been waiting for this for some time, at first glance it seems like you've done a wicked good job!

ClickHeReDec 18, 2005 10:02AM
You're in for a good read, but the code is well structured and OOP, so you shouldn't have any difficulties to manage to see how I proceeded into making all this.

ClickHeReDec 17, 2005 5:05PM
If you need to post suggestions or bugs, please use this bug tracker tool associated with my projects : http://dcx.scriptsdb.org/bug

and thanks for the review.

Only thing needed now is people using it and community stuff building around it : tutorials, help in other languages amd maybe a DCX Studio!

Text edited by author on Dec 17, 2005 @ 7:05PM


FeeteRDec 18, 2005 6:47AM
quote:
ClickHeRe said:

If you need to post suggestions or bugs, please use this bug tracker tool associated with my projects : http://dcx.scriptsdb.org/bug

and thanks for the review.

Only thing needed now is people using it and community stuff building around it : tutorials, help in other languages amd maybe a DCX Studio!
nice...nice... DCX Studio ;)

gr33nyDec 18, 2005 7:58AM
a dcx studio would kick some serious ass!

MicEikenDec 18, 2005 4:40AM
OWNS! good job * 100

MpdreamzDec 17, 2005 6:02PM
Myggan did you edit my review ? lol

DCX rules! go download now :)

mygganDec 17, 2005 6:22PM
Nope. I read yours though :)

MpdreamzDec 17, 2005 6:32PM
Its scaringly alike LOL
:p

mygganDec 17, 2005 6:48PM
We both brought up the biggest and most interesting parts, I don't see how that makes them "scaringly alike".

MpdreamzDec 17, 2005 11:16PM
Im not accusing ya man lol its just funny :p

twigboyDec 17, 2005 7:39PM
only problem i'd see now is oldschool MDX users will take some time to adjust to the DCX way of doing things
apart from that, this is one hell of an update for mIRC dialogs!

nice work clickhere!

ShadowKlownDec 17, 2005 5:54PM
I do like this dll and commend ClickHeRe for his work on it.

Why compare it with mdx or boast that it is superior? This dll just came out so of course it's got new, more powerful features, but let's not forget that when mdx came out it was the same way, i'm sure down the road, if mirc does prove to stay alive that a new and better dll then even this one will be released. Just saying...

ClickHeReDec 17, 2005 7:04PM
Sure, some crazy guy will release a new similar DLL for the new Windows Vista API !!!

And it ain't gonna be me =]

Text edited by author on Dec 17, 2005 @ 7:04PM


FeeteRDec 17, 2005 5:59PM
ROX !!! ClickHeRe you are BEST ! :D

MadsonDec 17, 2005 5:57PM
hehe... finally finished. so what..? we mark the beginning of a new era of mirc scripts

SoultechDec 17, 2005 5:02PM
Great stuff. Loads easier than MDX. 10 out of 10.



Create New Post

You must be logged in to post messages.