Industrial Strength JavaScript and DHTML Menus
About Us
Testimonials
Contact Us
Our Distinguished Clients
Investing in Non-Profits
Where Are We
Privacy Policy
Software Licensing Agreement
DHTML JavaScript Menu
Product Information
Page Integration
Quick Reference Guides
Embedding Into a Table or DIV
Purchase
Back To Start Of Archive
Taken From The Forum: Help & Support for DHTML Menu Version 5+
Forum Topic: Click to view post
Last Updated: Saturday July 14 2012 - 06:07:41
Problems after Upgrading the version 5.03
Poster: Martin
Dated: Wednesday February 25 2004 - 16:18:45 GMT
After Upgrading from Version 5.0 to 5.03 some formating things are gone.
Before:
After:
To be honest: You should invest a bit more time to test a new release
Poster: Maz
Dated: Wednesday February 25 2004 - 16:35:03 GMT
Hi Martin,
I just pointed out this problem in menustyle post, its the difference between 3d and 3D, or using onborder & offborder 1px solid #....,
instead of borderstyle.
I tend to agree with you, it might be better not to rush a new release now.
thanks,
maz
Poster: Martin
Dated: Wednesday February 25 2004 - 17:03:42 GMT
Hmm, my style worked for tons of RC's without any problems. I can't see any reason for a change.
This is the style:
Code:
with(NavSub1Style=new mm_style()){
fontfamily='Verdana,Arial';
fontstyle='normal';
fontweight='normal';
fontsize='11';
padding=3;
align='left';
offcolor='#FFFFFF';
oncolor='#FFFFFF';
offbgcolor='#C4BF8A';
onbgcolor='#ABA361';
pagecolor='#FFFFFF';
pagebgcolor='#ABA361';
separatorcolor='#343535';
separatorsize='2';
bordercolor='#000000';
borderwidth='1';
borderstyle='raised';
low3dcolor='#ABA361';
high3dcolor='#FFFFFF';
swap3d=1;
subimage='images/icons/arrow_right12x11_0.gif';
onsubimage='images/icons/arrow_right12x11_1.gif';
}
fontfamily='Verdana,Arial';
fontstyle='normal';
fontweight='normal';
fontsize='11';
padding=3;
align='left';
offcolor='#FFFFFF';
oncolor='#FFFFFF';
offbgcolor='#C4BF8A';
onbgcolor='#ABA361';
pagecolor='#FFFFFF';
pagebgcolor='#ABA361';
separatorcolor='#343535';
separatorsize='2';
bordercolor='#000000';
borderwidth='1';
borderstyle='raised';
low3dcolor='#ABA361';
high3dcolor='#FFFFFF';
swap3d=1;
subimage='images/icons/arrow_right12x11_0.gif';
onsubimage='images/icons/arrow_right12x11_1.gif';
}
Poster: Maz
Dated: Wednesday February 25 2004 - 17:15:17 GMT
Darn! you have both
I just discovered those problems last night by changing 3d to 3D will bring back separators, but will turn off 3d borders unless you use offborder and onborder eg. 1px solid #....;
Its like pulling a thread and you see it all the way along the material.
Its your choice to hold on this one
Regards,
maz
Poster: Martin
Dated: Wednesday February 25 2004 - 17:23:40 GMT
Hi maz,
oh my holy s.... are we now case sensitive? i can't find an difference between
"3d" and "3D"? Did i miss something?
Poster: Maz
Dated: Wednesday February 25 2004 - 17:36:34 GMT
No you didn't miss anything, its a little tangled web and I can I only know what's happening on the mac for sure. Besides me, you are the only other person noticing separators missing and I got mine back by using a capital D. Then I ran into the border problem.
Removing borderstyles for onborder and offborder appears to fix some problems with the border at the moment.
maz
Poster: kevin3442
Dated: Wednesday February 25 2004 - 18:21:05 GMT
Martin wrote:
Hi maz,
oh my holy s.... are we now case sensitive? i can't find an difference between
"3d" and "3D"? Did i miss something?
oh my holy s.... are we now case sensitive? i can't find an difference between
"3d" and "3D"? Did i miss something?
There actually isn't a "3d" vs a "3D". The property names are case sensitive, low3dcolor and high3dcolor (as well as other property names). When you use low3dcolor and high3dcolor, they take the place of your separators, so low3dcolor and high3dcolor supercede various separator properties. For example, after setting low3dcolor and high3dcolor, you could remove separatorcolor altogether and its removal would have absolutely no effect. So, if you have separator properties defined in your style along with low3dcolor and high3dcolor, then the low3dcolor and high3dcolor take precedence. But if you remove low3dcolor and high3dcolor, then the standard separators should re-assert themselves.
Knowing that, what's actually happening in Maz's tests is as follows:
(1) v5.03 has apparently introduced a bug that eliminates the visual effect of high3dcolor and low3dcolor in vertical menus (i.e., the horizontal 3d separators have disappeared).
(2) Even so, if high3dcolor and low3dcolor are defined in the style, then they take precedence, suppressing the standard "2d" separators... hence, you get no separators at all in your vertical menus.
(3) If you change "high3dcolor" to "high3Dcolor", then "high3dcolor" no longer exists in the style and therefore has no effect; "high3Dcolor" also has no effect at that point, because it isn't a menu property. So, what happens if you change "high3dcolor" and "low3dcolor" to "high3Dcolor" and "low3Dcolor"?... The same thing that would happen if you deleted them entirely. Keep in mind that, under normal circumstances, if you have normal separators as well as low3dcolor and high3dcolor defined in the style, then deleting the two 3d properties from the style would cause the standard separators to reassert themselves.
The main problem, of course, is that v5.03 has a bug that prevents high3dcolor and low3dcolor from working in vertical menus (although they still work in horizontal menus). I'm sure that'll get fixed soon.
Martin wrote:
To be honest: You should invest a bit more time to test a new release.
A valid point, of course. Although I'm sure you'll also admit that, given the number of possible combinations of properties and different approaches to creating menus, it would be extremely difficult and perhaps even impractical to test every possibility, especially without a huge staff to do so. Given that, plus generally good publishing practices, it should also be incumbent upon the end user to test the latest release of the menu scripts, with his or her specific implementation of the menu, on a staging site or page, before uploading the updated scripts to a functional site... at least in my own humble opinion.
Cheers,
Kevin
Poster: kevin3442
Dated: Wednesday February 25 2004 - 18:29:45 GMT
Geez... I wrote all that and by the time I posted it, Andy had already posted a fix in 5.04. Man, I gotta learn to type faster or type less.
Kevin
Poster: John
Dated: Wednesday February 25 2004 - 18:31:33 GMT
My fault. It was out a half hour before I caught it. That would have saved you the typing...
Gotta stop napping so much
Poster: Martin
Dated: Wednesday February 25 2004 - 19:02:10 GMT
Hi kevin.
Thanks for your help. If every keystroke would give you a buck, you might be a millionaire
I will wait for the next update to get my problem fixed.
As a programmer, i'm used to test my applications after minor and major changes. To do that, I use a test-scenario and sometimes i use an automated testing program.
To avoid errors like we have now, i would be enough to click trough all samples menues with the new RC or version. All basic and a lot of the advanced features would be verified. I did that a few minutes ago and I used only a few minutes. This would save time and money for everybody.
A "change log" is must also.
As a ColdFusion programmer, I have to concentrate my small brain to the main application. The menu system is only a small part of the application. After realizing an error in the menu, i have to get back into the syntax of the menu again and again. All parameters of the menu are stored in a database and/or are generated at runtime. This complicates any changes to the menu and needs some time to get back into this stuff, especially if the menu suffers with backwards compatibilty issues or non documented changes to the syntax. That is the reason why i ask for more testing and a change log (database)
Poster: John
Dated: Wednesday February 25 2004 - 19:21:28 GMT
Martin wrote:
I will wait for the next update to get my problem fixed.
Wait no longer - it's already posted!
Martin wrote:
To avoid errors like we have now, i would be enough to click trough all samples menues with the new RC or version. All basic and a lot of the advanced features would be verified. I did that a few minutes ago and I used only a few minutes. This would save time and money for everybody.
Trust me - Andy and his staff do test the changes before they are posted. However, as a programmer (and I write CF as well), you know that not every possible combination and item can be tested, regardless of how good your testing system is. So, sometimes something gets through. OK, I can live with that. Why? Because I understand the unreal complexity of this system and the above-and-beyond dedication Andy has put into this product. Step back and give the man a break. You won't find this dedication any place else that I know of, and we've got a hell of a product for a really cheap price.
Martin wrote:
A "change log" is must also.
Coming, as Andy promised. Patience.
Poster: Andy
Dated: Wednesday February 25 2004 - 19:23:25 GMT
For your information, there is a live change log at http://www.milonic.com/menuvinfo.php
Cheers
Andy
Poster: John
Dated: Wednesday February 25 2004 - 19:31:45 GMT
Heh - same place it's always been. I just never got around to looking.
So much for that "problem"...
Poster: kevin3442
Dated: Wednesday February 25 2004 - 20:42:32 GMT
Hi Martin,
Martin wrote:
...Thanks for your help....
No problem. Glad to help.
Quote:
I will wait for the next update to get my problem fixed.
It's already fixed. v5.04.
Quote:
As a programmer, i'm used to test my applications after minor and major changes. To do that, I use a test-scenario and sometimes i use an automated testing program.
I do the same.
Quote:
To avoid errors like we have now, i would be enough to click trough all samples menues with the new RC or version. All basic and a lot of the advanced features would be verified...
I respect your opinion, especially since you are a long-time user. But I have to disagree with you on this point. First, not every feature has an example. Second, features often interact, and there would not necessarily be a sample of various important combinations.
There are two larger points to make, however.
(1) I think your point seems to assume that there is not testing at all. I happen to know that Milonic usually does spend significant time testing a release before posting it. (The moderators of this forum -- John (jgillett), Dave (Hergio), and myself -- are not involved in this testing because we do not work for Milonic.) As with all of us, however, the people at Milonic are human, and sometimes things get past a person. Would it be fair to assume that there have been occasions in the past where a small bug has gotten past you in your own programming?
Quote:
As a ColdFusion programmer, I have to concentrate my small brain to the main application. The menu system is only a small part of the application.
(2) Even so, the ultimate responsibility for the quality of a site lies with the person who is publishing that site. Consider an analogy. If an end user of one of our software products notices a problem with the product, and we trace it back to a .dll in a third-party product we incorporate into ours, we will of course notify the producer of that .dll. But the end user will hold us responsible, as they should, not the producer of the .dll. So, while I agree that testing at Milonic is important, I also maintain that it is at least equally important for someone to test a new menu code release before publishing it to his or her site. And as little time as you say it took you to click through all of the samples on the Milonic site, I would imagine that it should take even less time for a person to test a new release with his or her own menu implementation before uploading to his or her site. Personally, I would never upload a new script to my site without testing it first.
Quote:
A "change log" is must also.
There has been one since v5.0 was released. You'll find it at http://www.milonic.com/menuvinfo.php (where the old v3 version info was)
Quote:
After realizing an error in the menu, i have to get back into the syntax of the menu again and again. All parameters of the menu are stored in a database and/or are generated at runtime. This complicates any changes to the menu and needs some time to get back into this stuff, especially if the menu suffers with backwards compatibilty issues or non documented changes to the syntax.
I'm not sure I understand the point here. There haven't been any changes to menu_data code syntax, documented or otherwise, for a long long time... the last ones were what... RC19 or so? And even then, it was pretty minor. But regardless... this particular issue was simply a small bug in the base code, requiring no changes on your end to fix (as you pointed out, the same code worked for many RCs). So I don't get the point about having to get back into the menu syntax etc.???
I hope you don't find any of this to seem disrespectful. Just a difference of opinion.
Cheers,
Kevin
Poster: kevin3442
Dated: Wednesday February 25 2004 - 20:46:07 GMT
Geeeez! Did it again. Posted all that then came to find out that others had already made several of the same points. That'll teach me to start a reply, then go get lunch, then come back and finish the reply.
Kevin
Poster: Martin
Dated: Wednesday February 25 2004 - 21:40:36 GMT
Hi Kevin,
Don't get me wrong: Take this postings as comments or as an open discussion only. We now have the first feedback, maybe as a result of this discussion: We know now the location of a change log
(did I missed that before? If yes, I apology my barking).
i always test the menu on my development-server before rollout. This is a must.
Cool, version 5.04 fixed the problems.
Poster: John
Dated: Wednesday February 25 2004 - 22:53:07 GMT
Martin wrote:
We know now the location of a change log (did I missed that before? If yes, I apology my barking).
(did I missed that before? If yes, I apology my barking).Apology not necessary (but accepted anyway). It was there - I missed it, too!
Martin wrote:
Cool, version 5.04 fixed the problems.
And that is the bottom line - right?
Glad it's working.