Re: Giving up on DW 2004 MX
doc.write and innerHTML is the same thing...it's all writing out html with _javascript_, and it's old, lame, and slow. I'd though that was implied. It's all DOM 1. I wouldn't even mind DOM 1 if it was fully implemented, but it's not It's clear to me you just like to complain for the sake of it. I was having the impression you would like to discuss, my mistake. I apologize with the list for wastiung the bandwith Massimo Foti Certified Dreamweaver MX Developer Certified Advanced ColdFusion MX Developer http://www.massimocorner.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
Nicely done on ignoring every point I made, including the request to back up your false claims about focus. I still feel DW's scripting API is far less powerful than Homesite's, and I'd welcome any attempt to prove my any of the facts I laid out in defense of my opinion wrong. This whole thing started out with what I felt was a positive post about the DW API, including an example of an extension I wrote showing it off rather nicely I thought. You disagreed with my opinion that I tacked on at the end, and still haven't backed it up with any facts. To me, it seems to me that you are the one wanting to complain about my opinions for no reason that I can see. You didn't even look at the extension or you wouldn't have asked what kind of extension needs recurring dir listings. Why you would go fishing for a debate, then whine about it when you get one is beyond me. ...and since I have no issues against responding to Ad Hominem attacks in kind...if you don't realize doc.write and innerHTML, part of DOM1, and over 6 years old, are one and the same conceptually, you really aren't worth discussing the issue with anyway. Kinda makes me want to whip together some extensions and see if they sell. I thought I went out of my way to be respectful in my post (which I just reread to make sure, and I'm still not sure what got you so defensive. I do apologize for any unintended slight. The ones above are quite intended though.), and I expect the same in return. Otherwise, you get what you give. -- mailto:[EMAIL PROTECTED] Friday, October 17, 2003, 1:29:39 AM, you wrote: doc.write and innerHTML is the same thing...it's all writing out html with _javascript_, and it's old, lame, and slow. I'd though that was implied. It's all DOM 1. I wouldn't even mind DOM 1 if it was fully implemented, but it's not MTeF It's clear to me you just like to complain for the sake of it. I was having MTeF the impression you would like to discuss, my mistake. MTeF I apologize with the list for wastiung the bandwith [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX (Please End)
Hey guys, can you give it a rest? a) no system is perfect for all b) if you don't like it, suggest a change my 2 cents Cutter jon hall wrote: Thursday, October 16, 2003, 10:37:33 AM, you wrote: MTeF I strongly disagree with this. Both about the documentation and the MF power MTeF :-) Oh really... :) MF Just tell me about something that you would like to implement as DW's MF extension and you can't due to the API's limitations For one example, setting focus. Focus needs to be able to be set from anywhere, to anywhere. This is especially problematic with dynamic content in a floater as doc.write has, i assume unintended, consequences in regards to focus. Floaters themselves need all of the DOM events...onmouseover is a big one. Onmouseover...floaters need to be able to be focused. Onrightclick is another big missing one. How exactly does an extremely small subset of DOM 1 that is implemented unevenly across the different objects qualify as powerful? To say nothing of DOM 2 or 3. MF See above, what part of DOM 2 or 3 do you need inside the API, and why? doc.write being the only way to dynamically alter content is so 5 years ago, slow, and has obvious code maintenance problems. The world has DOM 2 now. Fourth generation browsers are dead, and doc.write is lame. How does the fact that all the menus are very nicely defined in XML files, but no one has thought to distribute DTD's of any kind qualify as well documented? MF Do you really feel like it's so hard to read without a DTD? MF Do you think HS's stuff is better documented? A simple DTD says so much about an XML document...it's vastly superior to the few paragraphs and examples given. Homesite's built in objects and functions are documented clearly and named logically. It also benefits from the fact that tons of preexisting documentation exists for the WSH languages and COM objects. How can DW's data connectivity compare in any regard to ADO for power? MF I never felt the need to connect to a datasource from a DW's extension, but, MF apart from C++, you can leverage Flash Remoting too I can't remember who developed it, but I'm sure you have seen that cool new DW data wizard that was recently released. It's great...except DW's data limitations wont allow an editable grid, just viewing. Even WebMatrix allows data editing, and it's free. DW allows only JS or C, HS allows any language built on WSH, meaning VBS, JS, Kix, etc., and any language a COM object can be written in. MF There is a huge difference here, DW API are cross-platform. I only use DW on one platform...I don't see why I have to be limited. Would it be hard to allow Windows people to use WSH and allow Mac people to use AppleScript? Why the heck is DWFile so slow? MF How many files you need to process with it? I used it for up to 2-3.000 MF files testing my site-wide extensions, it does the job, I never felt the MF need for anything faster (remember it's cross platform too) Directory listings read from the HD directly every time instead of using the Windows API's ability to cache directory listings. I also can't speak to the C API, knowing very little C, but how many web developers know C? MF I don't, but I was still able to do a few not too trivial things using DW's MF API The only thing going for DW is the UI extensibility, which is awesome, MF And leaves HS in the dust here... :-) MF Try this for example: MF http://www.communitymx.com/content/article.cfm?cid=A1EDDF56F77EE7CA A custom floater in Flash? Nice looking...still has all of Flash's UI problems like lack of right-click, and scroll button though. I want to extend my IDE because I want more usability out of my IDE, not even more usability problems. DW does trump HS with the ability to alter the UI, but just putting a sticker on the side of the box doesn't make it so. It's has to fully deliver that capability. I can't help but feel that the whole DW extensibility thing has not enough resources, meaning people working on it, or it has too many, and not enough organization. Maybe it's because it has to run on the Mac as well that is holding it back. MF I am not pretending DW's API is perfect, but I stand by my words saying that MF I strongly disagree with your statement about HS's extensibility being more MF powerful or better documented I think Mozilla is the model of what DW extensibility model want's to be. XUL/XBL/XPCOM kicks butt...or even HTML/DOM2/XML Events. Whatever the solution is, DW needs it. It's really lagging. MF Well, actually DW predates Mozilla, the XML menus were based on the very MF early draft of XUL (back in 1999) Four years...The extensibility team been on hiatus since then? I know this stuff isn't trivial to implement, but it's what I expect when I look over and see guys using WebMatrix and VS.Net. I never claimed to be a reasonable guy either :) -- jon
Re: Giving up on DW 2004 MX
Thursday, October 16, 2003, 12:54:15 AM, you wrote: MTeF jon hall [EMAIL PROTECTED] wrote in message MTeF news:[EMAIL PROTECTED] Yeah, that's the best part about it...but the script API is even less documented, and less powerful (can't call COM objects) than Homesite's. MTeF I strongly disagree with this. Both about the documentation and the power MTeF :-) Oh really... :) How exactly does an extremely small subset of DOM 1 that is implemented unevenly across the different objects qualify as powerful? To say nothing of DOM 2 or 3. How does the fact that all the menus are very nicely defined in XML files, but no one has thought to distribute DTD's of any kind qualify as well documented? How can DW's data connectivity compare in any regard to ADO for power? DW allows only JS or C, HS allows any language built on WSH, meaning VBS, JS, Kix, etc., and any language a COM object can be written in. Why the heck is DWFile so slow? I also can't speak to the C API, knowing very little C, but how many web developers know C? The only thing going for DW is the UI extensibility, which is awesome, the only other closed source IDE with that ability that I know of is VS, but it's stuck with a less than Netscape 4 level DOM, and limited the HTML to define the look and feel, with doc.write the only way to make content dynamic. I can't help but feel that the whole DW extensibility thing has not enough resources, meaning people working on it, or it has too many, and not enough organization. Maybe it's because it has to run on the Mac as well that is holding it back. I think Mozilla is the model of what DW extensibility model want's to be. XUL/XBL/XPCOM kicks butt...or even HTML/DOM2/XML Events. Whatever the solution is, DW needs it. It's really lagging. -- mailto:[EMAIL PROTECTED] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
MTeF I strongly disagree with this. Both about the documentation and the power MTeF :-) Oh really... :) Just tell me about something that you would like to implement as DW's extension and you can't due to the API's limitations How exactly does an extremely small subset of DOM 1 that is implemented unevenly across the different objects qualify as powerful? To say nothing of DOM 2 or 3. See above, what part of DOM 2 or 3 do you need inside the API, and why? How does the fact that all the menus are very nicely defined in XML files, but no one has thought to distribute DTD's of any kind qualify as well documented? Do you really feel like it's so hard to read without a DTD? Do you think HS's stuff is better documented? How can DW's data connectivity compare in any regard to ADO for power? I never felt the need to connect to a datasource from a DW's extension, but, apart from C++, you can leverage Flash Remoting too DW allows only JS or C, HS allows any language built on WSH, meaning VBS, JS, Kix, etc., and any language a COM object can be written in. There is a huge difference here, DW API are cross-platform. Why the heck is DWFile so slow? How many files you need to process with it? I used it for up to 2-3.000 files testing my site-wide extensions, it does the job, I never felt the need for anything faster (remember it's cross platform too) I also can't speak to the C API, knowing very little C, but how many web developers know C? I don't, but I was still able to do a few not too trivial things using DW's API The only thing going for DW is the UI extensibility, which is awesome, And leaves HS in the dust here... :-) Try this for example: http://www.communitymx.com/content/article.cfm?cid=A1EDDF56F77EE7CA I can't help but feel that the whole DW extensibility thing has not enough resources, meaning people working on it, or it has too many, and not enough organization. Maybe it's because it has to run on the Mac as well that is holding it back. I am not pretending DW's API is perfect, but I stand by my words saying that I strongly disagree with your statement about HS's extensibility being more powerful or better documented I think Mozilla is the model of what DW extensibility model want's to be. XUL/XBL/XPCOM kicks butt...or even HTML/DOM2/XML Events. Whatever the solution is, DW needs it. It's really lagging. Well, actually DW predates Mozilla, the XML menus were based on the very early draft of XUL (back in 1999) Massimo Foti Certified Dreamweaver MX Developer Certified Advanced ColdFusion MX Developer http://www.massimocorner.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
Can you send a copy over to me, or send the URL? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
Thursday, October 16, 2003, 10:37:33 AM, you wrote: MTeF I strongly disagree with this. Both about the documentation and the MF power MTeF :-) Oh really... :) MF Just tell me about something that you would like to implement as DW's MF extension and you can't due to the API's limitations For one example, setting focus. Focus needs to be able to be set from anywhere, to anywhere. This is especially problematic with dynamic content in a floater as doc.write has, i assume unintended, consequences in regards to focus. Floaters themselves need all of the DOM events...onmouseover is a big one. Onmouseover...floaters need to be able to be focused. Onrightclick is another big missing one. How exactly does an extremely small subset of DOM 1 that is implemented unevenly across the different objects qualify as powerful? To say nothing of DOM 2 or 3. MF See above, what part of DOM 2 or 3 do you need inside the API, and why? doc.write being the only way to dynamically alter content is so 5 years ago, slow, and has obvious code maintenance problems. The world has DOM 2 now. Fourth generation browsers are dead, and doc.write is lame. How does the fact that all the menus are very nicely defined in XML files, but no one has thought to distribute DTD's of any kind qualify as well documented? MF Do you really feel like it's so hard to read without a DTD? MF Do you think HS's stuff is better documented? A simple DTD says so much about an XML document...it's vastly superior to the few paragraphs and examples given. Homesite's built in objects and functions are documented clearly and named logically. It also benefits from the fact that tons of preexisting documentation exists for the WSH languages and COM objects. How can DW's data connectivity compare in any regard to ADO for power? MF I never felt the need to connect to a datasource from a DW's extension, but, MF apart from C++, you can leverage Flash Remoting too I can't remember who developed it, but I'm sure you have seen that cool new DW data wizard that was recently released. It's great...except DW's data limitations wont allow an editable grid, just viewing. Even WebMatrix allows data editing, and it's free. DW allows only JS or C, HS allows any language built on WSH, meaning VBS, JS, Kix, etc., and any language a COM object can be written in. MF There is a huge difference here, DW API are cross-platform. I only use DW on one platform...I don't see why I have to be limited. Would it be hard to allow Windows people to use WSH and allow Mac people to use AppleScript? Why the heck is DWFile so slow? MF How many files you need to process with it? I used it for up to 2-3.000 MF files testing my site-wide extensions, it does the job, I never felt the MF need for anything faster (remember it's cross platform too) Directory listings read from the HD directly every time instead of using the Windows API's ability to cache directory listings. I also can't speak to the C API, knowing very little C, but how many web developers know C? MF I don't, but I was still able to do a few not too trivial things using DW's MF API The only thing going for DW is the UI extensibility, which is awesome, MF And leaves HS in the dust here... :-) MF Try this for example: MF http://www.communitymx.com/content/article.cfm?cid=A1EDDF56F77EE7CA A custom floater in Flash? Nice looking...still has all of Flash's UI problems like lack of right-click, and scroll button though. I want to extend my IDE because I want more usability out of my IDE, not even more usability problems. DW does trump HS with the ability to alter the UI, but just putting a sticker on the side of the box doesn't make it so. It's has to fully deliver that capability. I can't help but feel that the whole DW extensibility thing has not enough resources, meaning people working on it, or it has too many, and not enough organization. Maybe it's because it has to run on the Mac as well that is holding it back. MF I am not pretending DW's API is perfect, but I stand by my words saying that MF I strongly disagree with your statement about HS's extensibility being more MF powerful or better documented I think Mozilla is the model of what DW extensibility model want's to be. XUL/XBL/XPCOM kicks butt...or even HTML/DOM2/XML Events. Whatever the solution is, DW needs it. It's really lagging. MF Well, actually DW predates Mozilla, the XML menus were based on the very MF early draft of XUL (back in 1999) Four years...The extensibility team been on hiatus since then? I know this stuff isn't trivial to implement, but it's what I expect when I look over and see guys using WebMatrix and VS.Net. I never claimed to be a reasonable guy either :) -- jon mailto:[EMAIL PROTECTED] [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
MF Just tell me about something that you would like to implement as DW's MF extension and you can't due to the API's limitations For one example, setting focus. Focus needs to be able to be set from anywhere, to anywhere. This is especially problematic with dynamic content in a floater as doc.write has, i assume unintended, consequences in regards to focus. I really don't want to sound rude or offend you, but I have the strong feeling you haven't spend that much time looking at DW's API. Yes, you can set focus (of course) and document.write() isn't supported at all inside extension's GUI. DW expose innerHTML both as a read/write property oaters themselves need all of the DOM events...onmouseover is a big e. Onmouseover...floaters need to be able to be focused. Onrightclick is another big missing one. Floaters support a bunch of events. Two you may want to investigate are onShow() and onHide() doc.write being the only way to dynamically alter content is so 5 years ago, slow, and has obvious code maintenance problems. The world has DOM 2 now. Fourth generation browsers are dead, and doc.write is lame. I really have can't imagine how you got into this idea that DW's use document.write()... It's clearly stated inside the docs that document.write() isn't supported in extensions GUIs and you have to use the DOM (same for editing documents) A simple DTD says so much about an XML document...it's vastly superior to the few paragraphs and examples given. Sincerely, unless I need to validate, I don't think a DTD is a good documentation by itself. But I guess it's a matter of tastes Homesite's built in objects and functions are documented clearly and named logically. Would you mind giving me an exmple where DW doesn't follow this standards? It also benefits from the fact that tons of preexisting documentation exists for the WSH languages and COM objects. That's the good thing of HS's extensibility but, again, your mileage may vary, I can't stand VBScript and I always find annoying to see that so many documentation in this area focus on VBScript. DW internally use Mozilla's Rhino _javascript_ 1.5 engine, and there is plenty of preexisting documentation on it too, much more than the one available for WSH. I can't remember who developed it, but I'm sure you have seen that cool new DW data wizard that was recently released. It's great...except DW's data limitations wont allow an editable grid, just viewing. Are you talking about the one included in DRK? As far as I know it use Java under the hood (with a C++ Java bridge). What's the purpose of having an editable grid inside an extension? Of course, if you need it badly, you can use C++ or Flash for it. I only use DW on one platform...I don't see why I have to be limited. Would it be hard to allow Windows people to use WSH and allow Mac people to use AppleScript? What I like about DW is that I can develop an extension on my Windows box and distribute or sell it cross-platform. That's a huge benefit since, last time I heard, around 40% of DW users base is on the Mac. Directory listings read from the HD directly every time instead of using the Windows API's ability to cache directory listings. Back in DW 4 days I sold a quite succeful extension, a Snippets Floater. It uses DWFile for directory listing, people used it with 1000+ snippets and it perfomed just fine, actually faster than DW's MX native implementation. Would you mind showing me a scenario were this would affect a real world extension? How many recurring directory listing would you need and why? A custom floater in Flash? Nice looking... It's doable since DW 2 still has all of Flash's UI problems like lack of right-click, and scroll button though. Have you checked Flash 2004? I think not :-) MF Well, actually DW predates Mozilla, the XML menus were based on the very MF early draft of XUL (back in 1999) Four years...The extensibility team been on hiatus since then? No, but there was no need to update the XML structure. What's wrong with that? I never claimed to be a reasonable guy either :) Me either :-) Massimo Foti Certified Dreamweaver MX Developer Certified Advanced ColdFusion MX Developer http://www.massimocorner.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
doc.write being the only way to dynamically alter content is so 5 years ago, slow, and has obvious code maintenance problems. The world has DOM 2 now. Fourth generation browsers are dead, and doc.write is lame. Just to be 100% clear. DW API never used document.write(), they use the DOM since the very beginning, dating back to 1998. Pretty much before any browser start supporting it One of the engineers behind DW API at that time was part of W3C DOM working group (another one was on the CSS group). His name is Joe Marini and, more recently, he wrote one of the very few books that cover the topic: Document Object Model by Joe Marini Paperback - 360 pages (August 2002) Osborne McGraw-Hill ISBN: 0072224363 Massimo Foti Certified Dreamweaver MX Developer Certified Advanced ColdFusion MX Developer http://www.massimocorner.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
Thursday, October 16, 2003, 2:20:37 PM, you wrote: MF Just tell me about something that you would like to implement as DW's MF extension and you can't due to the API's limitations For one example, setting focus. Focus needs to be able to be set from anywhere, to anywhere. This is especially problematic with dynamic content in a floater as doc.write has, i assume unintended, consequences in regards to focus. MTeF I really don't want to sound rude or offend you, but I have the strong MTeF feeling you haven't spend that much time looking at DW's API. Yes, you can MTeF set focus (of course) and document.write() isn't supported at all inside MTeF extension's MTeF GUI. DW expose innerHTML both as a read/write property Show me the code to set focus anywhere in a floater onmouseover the floater itself. It doesn't exist. The focus() method is _only_ available on form objects according to the documentation. Custom floaters are really the coolest thing about DW so that's where I think the problem is most glaring. doc.write and innerHTML is the same thing...it's all writing out html with _javascript_, and it's old, lame, and slow. I'd though that was implied. It's all DOM 1. I wouldn't even mind DOM 1 if it was fully implemented, but it's not. Hell, replace all of the HTML crap with Flash + Royale (if it's as good as advertised), and I could care about the DOM support even less. btw, I spent two weeks looking at 2004 in my spare time before my trial was up. oaters themselves need all of the DOM events...onmouseover is a big e. Onmouseover...floaters need to be able to be focused. Onrightclick is another big missing one. MTeF Floaters support a bunch of events. Two you may want to investigate are MTeF onShow() and onHide() onshow and onhide have nothing to do with onmouseover, or onrightclick, and onblur, and ondoubleclick, and every other DOM event. doc.write being the only way to dynamically alter content is so 5 years ago, slow, and has obvious code maintenance problems. The world has DOM 2 now. Fourth generation browsers are dead, and doc.write is lame. MTeF I really have can't imagine how you got into this idea that DW's use MTeF document.write()... MTeF It's clearly stated inside the docs that document.write() isn't supported in MTeF extensions GUIs and you have to use the DOM (same for editing documents) Yeah...the old, lame, and slow based DOM. See above. A simple DTD says so much about an XML document...it's vastly superior to the few paragraphs and examples given. MTeF Sincerely, unless I need to validate, I don't think a DTD is a good MTeF documentation by itself. But I guess it's a matter of tastes You must really dislike all the W3C standards then. They seem to think they are great for documentation, and I would agree. Homesite's built in objects and functions are documented clearly and named logically. MTeF Would you mind giving me an exmple where DW doesn't follow this standards? Can't think of anything major off the top of my head, that isn't a personal preference, but the fact that the dom and dreamweaver object methods are so scattered around in different sections is annoying when you are not sure what you are looking for. It also benefits from the fact that tons of preexisting documentation exists for the WSH languages and COM objects. MTeF That's the good thing of HS's extensibility but, again, your mileage may MTeF vary, I can't stand VBScript and I always find annoying to see that so many MTeF documentation in this area focus on VBScript. MTeF DW internally use Mozilla's Rhino _javascript_ 1.5 engine, and there is plenty MTeF of preexisting documentation on it too, much more than the one available for MTeF WSH. I think JS 1.5 is great, but I'd bet a nickel a large number of people would trade it for VBS, or Kix, or Perl... I also own three books that cover various aspects of WSH or touch on it, and their are many more available. It's not the language that needs documented anyway...there isn't any _javascript_ docs in DW extensibility manuals. It's the objects and their methods. Extensibility is about allowing what the primary application developers do not have time to do, or what they haven't seen a need for. Not just different ways of doing what the app already does. I can't remember who developed it, but I'm sure you have seen that cool new DW data wizard that was recently released. It's great...except DW's data limitations wont allow an editable grid, just viewing. MTeF Are you talking about the one included in DRK? As far as I know it use Java MTeF under the hood (with a C++ Java bridge). MTeF What's the purpose of having an editable grid inside an extension? Of MTeF course, if you need it badly, you can use C++ or Flash for it. What's the purpose?! Obviously you haven't had the pleasure of working in an IDE that allows direct editing of a db table while working on a data heavy project. Do you think VS.Net goes as far as providing stored
Giving up on DW 2004 MX
Anybody else got this far. The product is flaky and some very basic stuff falls over. Oh well back to DW. Hope the first patch sorts out a load of stuff. Adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
re: Giving up on DW 2004 MX
I use it everyday for development and I don't have any issues with it. I use for CFC stuff for my RIA's. Other than a memory hog, I think DW 2004 is much better than the MX version. Clint Tredway www.digital12studios.com Original Message: Return-Path: [EMAIL PROTECTED] Wed Oct 15 05:01:13 2003 Received: from houseoffusion.com [64.118.64.245] by mail16.crystaltech.com with SMTP; Wed, 15 Oct 2003 05:01:13 -0700 Received: from LOCALHOST by LOCALHOST with ESMTP id CC7A93AA65EDD64AAC91A95603BA6CE8 Wed, 15 Oct 2003 08:01:13 -0400 Date: Wed, 15 Oct 2003 13:00:34 +0100 From: Adam Reynolds [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] Subject: Giving up on DW 2004 MX To: CF-Talk [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=_NextPart_000_1066204874_CFX_iMSMail_396336621 Content-Transfer-Encoding: 7bit Anybody else got this far. The product is flaky and some very basic stuff falls over. Oh well back to DW. Hope the first patch sorts out a load of stuff. Adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
I have to agree with Clint. DWMX 2K4 is a big improvement of DWMX. I admit that I still use Homesite+ for developing when running off of battery power because DW is such a memory hog, but when I am plugged in, DWMX 2004 is what I use. If I have a complaint, it would be with the VSS integration. It is still a bit kludge at best. _ From: Clint Tredway [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 7:36 AM To: CF-Talk Subject: re: Giving up on DW 2004 MX I use it everyday for development and I don't have any issues with it. I use for CFC stuff for my RIA's. Other than a memory hog, I think DW 2004 is much better than the MX version. Clint Tredway www.digital12studios.com Original Message: Return-Path: [EMAIL PROTECTED] Wed Oct 15 05:01:13 2003 Received: from houseoffusion.com [64.118.64.245] by mail16.crystaltech.com with SMTP; Wed, 15 Oct 2003 05:01:13 -0700 Received: from LOCALHOST by LOCALHOST with ESMTP id CC7A93AA65EDD64AAC91A95603BA6CE8 Wed, 15 Oct 2003 08:01:13 -0400 Date: Wed, 15 Oct 2003 13:00:34 +0100 From: Adam Reynolds [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] Subject: Giving up on DW 2004 MX To: CF-Talk [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=_NextPart_000_1066204874_CFX_iMSMail_396336621 Content-Transfer-Encoding: 7bit Anybody else got this far. The product is flaky and some very basic stuff falls over. Oh well back to DW. Hope the first patch sorts out a load of stuff. Adam _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
A problem that keeps popping up for me is a bug where the program doesn't recognise that a page has been saved when you do a ctrl-s or select save from the File menu. It remains with an * next to it. I have recently learnt that only clicking Save All gets around this. That's the most annoying bug I've found, but I haven't tried using much of the advanced features of it yet. -Gel -Original Message- From: Bruce Sorge [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 9:33 AM To: CF-Talk Subject: RE: Giving up on DW 2004 MX I have to agree with Clint. DWMX 2K4 is a big improvement of DWMX. I admit that I still use Homesite+ for developing when running off of battery power because DW is such a memory hog, but when I am plugged in, DWMX 2004 is what I use. If I have a complaint, it would be with the VSS integration. It is still a bit kludge at best. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
Was there something specific you wanted feedback on? Thanks, Calvin - Original Message - From: Adam Reynolds To: CF-Talk Sent: Wednesday, October 15, 2003 8:00 AM Subject: Giving up on DW 2004 MX Anybody else got this far. The product is flaky and some very basic stuff falls over. Oh well back to DW. Hope the first patch sorts out a load of stuff. Adam [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
That's the most annoying bug I've found, but I haven't tried using much of the advanced features of it yet. The main issue for me, and one I've posted about on other lists but haven't gotten responses on, is a real wierd one. It is so wierd I'm convinced it's my fault and I'm missing a config somewhere. Imagine the following directory structure: / /alpha /beta /alpha/admin /beta/admin Now, imagine you do a directory search. You get two results, one from alpha/admin and one from beta/admin. However, all you see is admin/x.cfm You can't tell _where_ the file is. But wait - it gets better. I open the file and I _still_ can't see where the file is. I have to actually do a save as to track it down. This just seems so wrong... yet it was enough of a problem to make me move back to HS+ 5.5 after using DWMX 2004 since it came out. Like I said, I'm sure I'm missing some simple option... right? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
Nope.Happens to me too.Seems to be an oversight IMHO. You can't tell _where_ the file is. But wait - it gets better. I open the file and I _still_ can't see where the file is. I have to actually do a save as to track it down. This just seems so wrong... yet it was enough of a problem to make me move back to HS+ 5.5 after using DWMX 2004 since it came out. Like I said, I'm sure I'm missing some simple option... right? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
If you're in code view/code pane of split view, have you tried hitting F5 before ctrl-S? Just a suggestion... -Scott -Original Message- From: Angel Stewart [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 7:06 AM To: CF-Talk Subject: RE: Giving up on DW 2004 MX A problem that keeps popping up for me is a bug where the program doesn't recognise that a page has been saved when you do a ctrl-s or select save from the File menu. It remains with an * next to it. I have recently learnt that only clicking Save All gets around this. That's the most annoying bug I've found, but I haven't tried using much of the advanced features of it yet. -Gel -Original Message- From: Bruce Sorge [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 9:33 AM To: CF-Talk Subject: RE: Giving up on DW 2004 MX I have to agree with Clint. DWMX 2K4 is a big improvement of DWMX. I admit that I still use Homesite+ for developing when running off of battery power because DW is such a memory hog, but when I am plugged in, DWMX 2004 is what I use. If I have a complaint, it would be with the VSS integration. It is still a bit kludge at best. _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
I'd agree here- little-if-any directory path detail available in the report window and opening the file doesn't glean any more context.Have you submitted this to the product team as a bug/request? http://www.macromedia.com/go/wish/ http://www.macromedia.com/go/wish/ -Scott -Original Message- From: Patricia G. L. Hall [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 3:49 AM To: CF-Talk Subject: RE: Giving up on DW 2004 MX Nope.Happens to me too.Seems to be an oversight IMHO. You can't tell _where_ the file is. But wait - it gets better. I open the file and I _still_ can't see where the file is. I have to actually do a save as to track it down. This just seems so wrong... yet it was enough of a problem to make me move back to HS+ 5.5 after using DWMX 2004 since it came out. Like I said, I'm sure I'm missing some simple option... right? _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
Nope - because again - I was convinced it was a setting somewhere that was just hidden. If this is the way it's supposed to be, I'll defintely report a bug on it. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
This is totally in Code view. THat's where I usually stay, and after I finish off writing a loop or osmething I typically do a Ctrl - S. It apparently saves the file, but the asterisk remains. Only when I click Save All does the asterisk disappear, indicating that the file is only now being considered by Dreamweaver as being saved. So I see that as being a problem. -Gel -Original Message- From: Scott Fegette [mailto:[EMAIL PROTECTED] If you're in code view/code pane of split view, have you tried hitting F5 before ctrl-S? Just a suggestion... -Scott [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
WEll I'll be. You're right. Even in Code view, I need to press F5 and then save, before it is considered Saved. I don't like that 'feature' if that's what it is. What's the point of that?? -Gel -Original Message- From: Scott Fegette [mailto:[EMAIL PROTECTED] If you're in code view/code pane of split view, have you tried hitting F5 before ctrl-S? Just a suggestion... -Scott [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
Good to hear that little 'test' worked, Angel!;) I'd consider this (borderline) 'expected' behavior when working in the code pane of Split view (the design display in split view isn't refreshed until you hit F5 after edits in the code pane- so I already was used to hitting F5 when working in that scenario to update the entire doc window regularly), but I'd agree that this isn't particularly intuitive in Code view specifically (no design view to refresh!).I do get the files to save correctly via cmd-S in Code view on Macs, however- so the inconsistency alone makes me guess it's not expected behavior. Definitely make your thoughts on this known (w/system info as this seems to be platform-specific behavior) via the wishlist/bug reporting form: http://www.macromedia.com/go/wish/ http://www.macromedia.com/go/wish/ thx! -Scott -Original Message- From: Angel Stewart [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 15, 2003 12:12 PM To: CF-Talk Subject: RE: Giving up on DW 2004 MX WEll I'll be. You're right. Even in Code view, I need to press F5 and then save, before it is considered Saved. I don't like that 'feature' if that's what it is. What's the point of that?? -Gel -Original Message- From: Scott Fegette [mailto:[EMAIL PROTECTED] If you're in code view/code pane of split view, have you tried hitting F5 before ctrl-S? Just a suggestion... -Scott _ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
Sent! As a bug :-) I don't think you should ever need to refresh the page in order to save it/have it recognised as being saved imNSho. :-) -Gel (in my NOT SO humble opinion) *grin* -Original Message- From: Scott Fegette [mailto:[EMAIL PROTECTED] Good to hear that little 'test' worked, Angel!;) I'd consider this (borderline) 'expected' behavior when working in the code pane of Split view (the design display in split view isn't refreshed until you hit F5 after edits in the code pane- so I already was used to hitting F5 when working in that scenario to update the entire doc window regularly), but I'd agree that this isn't particularly intuitive in Code view specifically (no design view to refresh!).I do get the files to save correctly via cmd-S in Code view on Macs, however- so the inconsistency alone makes me guess it's not expected behavior. Definitely make your thoughts on this known (w/system info as this seems to be platform-specific behavior) via the wishlist/bug reporting form: http://www.macromedia.com/go/wish/ http://www.macromedia.com/go/wish/ thx! -Scott [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
There is not a setting for this, so be sure to visit the wish form. However, someone should be able to whip up an extension to handle this pretty easily... - Calvin - Original Message - From: Raymond Camden To: CF-Talk Sent: Wednesday, October 15, 2003 2:14 PM Subject: RE: Giving up on DW 2004 MX Nope - because again - I was convinced it was a setting somewhere that was just hidden. If this is the way it's supposed to be, I'll defintely report a bug on it. [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
RE: Giving up on DW 2004 MX
DWMX extensions can modify the UI of the application itself? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
Yeah, that's the best part about it...but the script API is even less documented, and less powerful (can't call COM objects) than Homesite's. Once I figured it out, it left me wanting more power. There is a C API though. Here is shot of an extension I was making...it's docked on the far right. http://216.136.31.190/filepicker1.png -- jon mailto:[EMAIL PROTECTED] Wednesday, October 15, 2003, 4:51:30 PM, you wrote: RC DWMX extensions can modify the UI of the application itself? RC [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
I'm not sure who you are responding too, but if it was me, I did develop an inhouse extension that displays the current file path and current site in a toolbar. It doesn't write to the title bar, BUT... it is a bit more flexible in other areas :) - Calvin - Original Message - From: Raymond Camden To: CF-Talk Sent: Wednesday, October 15, 2003 4:51 PM Subject: RE: Giving up on DW 2004 MX DWMX extensions can modify the UI of the application itself? [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
Re: Giving up on DW 2004 MX
jon hall [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Yeah, that's the best part about it...but the script API is even less documented, and less powerful (can't call COM objects) than Homesite's. I strongly disagree with this. Both about the documentation and the power :-) Massimo Foti Certified Dreamweaver MX Developer Certified Advanced ColdFusion MX Developer http://www.massimocorner.com/ [Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
