Re: Back to button basics
hoverIcon is promising but has one bug: It reset icons to the normal Icon on mouseLeave, but alas, it does not reset changed buttons upon leaving the card. So, if you click a button that takes you to a different card, and your mouse is moving, whatever icons you are switching will stay stuck showing the hoverIcon. Upon returning to the card with the buttons, it looks strange indeed! With some buttons showing over states. I have sadly given up on hoverIcon and gone back to Chipp's idea of manually switching out icons, which works flawlessly. The only solution I can think of, is that upon going to a different card, Rev has to insert code that checks all icons on the card it's leaving, and resets any showing the hoverIcon to the regular Icon. Is this a Bugzillable issue? On Dec 5, 2006, at 9:30 PM, Tereza Snyder wrote: If I want rollover behavior, I would use the new hoverIcon property instead of the autoArm and armedIcon property ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Back to button basics
On 12/11/06 12:15 PM, Josh Mellicker [EMAIL PROTECTED] wrote: hoverIcon is promising but has one bug: It reset icons to the normal Icon on mouseLeave, but alas, it does not reset changed buttons upon leaving the card. So, if you click a button that takes you to a different card, and your mouse is moving, whatever icons you are switching will stay stuck showing the hoverIcon. Upon returning to the card with the buttons, it looks strange indeed! With some buttons showing over states. I have sadly given up on hoverIcon and gone back to Chipp's idea of manually switching out icons, which works flawlessly. The only solution I can think of, is that upon going to a different card, Rev has to insert code that checks all icons on the card it's leaving, and resets any showing the hoverIcon to the regular Icon. Is this a Bugzillable issue? Absolutely! And I'd recommend entering it NOW as they are working on fixing bugs for the 2.7.5 release and it would be great to get that fixed right away... Ken Ray Sons of Thunder Software, Inc. Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Back to button basics
Okay, I have not yet bugzilled yet, and this is not as major as other issues... and there is a fine workaround for now, just so everyone knows, I have just been working with this and if to fix the stuck over button problem, just set the hoverIcon to 0 (to disable it), set the armedIcon to the same as the icon and swap out the icon number manually on mouseEnter, this works perfectly. On Dec 11, 2006, at 11:24 AM, Ken Ray wrote: On 12/11/06 12:15 PM, Josh Mellicker [EMAIL PROTECTED] wrote: hoverIcon is promising but has one bug: It reset icons to the normal Icon on mouseLeave, but alas, it does not reset changed buttons upon leaving the card. So, if you click a button that takes you to a different card, and your mouse is moving, whatever icons you are switching will stay stuck showing the hoverIcon. Upon returning to the card with the buttons, it looks strange indeed! With some buttons showing over states. I have sadly given up on hoverIcon and gone back to Chipp's idea of manually switching out icons, which works flawlessly. The only solution I can think of, is that upon going to a different card, Rev has to insert code that checks all icons on the card it's leaving, and resets any showing the hoverIcon to the regular Icon. Is this a Bugzillable issue? Absolutely! And I'd recommend entering it NOW as they are working on fixing bugs for the 2.7.5 release and it would be great to get that fixed right away... Ken Ray Sons of Thunder Software, Inc. Web site: http://www.sonsothunder.com/ Email: [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
RE: Back to button basics
Tereza, 6. desember 2006 06:30, you wrote If all the buttons do is signal a state change that will be acted on later, I would put the following script in the group: Fantistical, Not only did you help me out - you threw in some lessons too. I'm enlightened and my head is in order. What an absolutely tremendous reply. Big handshake, Jan --- Jan Selid [EMAIL PROTECTED] ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Back to button basics
On Dec 6, 2006, at 2:25 AM, Jan Sælid wrote: 6. desember 2006 06:30, you wrote If all the buttons do is signal a state change that will be acted on later, I would put the following script in the group: Fantistical, Not only did you help me out - you threw in some lessons too. I'm enlightened and my head is in order. What an absolutely tremendous reply. Big handshake, You're welcome! Normally I'm so slow on the uptake that by the time I type in a reply to anyone, there are already five responses on the list. Last night the speedy answer guys must have been busy (or asleep). After I sent off my reply, though, I thought of one more bit of info. You could avoid having the script in the group (set the hilite of the target to not the hilite of the target) by using checkbox buttons to start with, because checkboxes inherently toggle hilites. Therefore, set their icon properties and leave their autohilite true. You can deal with the button names by hiding them (set their showName to false) or working with their textAlign property and margins. Glad to help, t -- Tereza Snyder Califex Software, Inc. www.califexsoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Back to button basics
On Dec 5, 2006, at 9:05 PM, Jan Sælid wrote: ... What I want to do is to just change the icon according to the state of onstate property. Should I use a visited icon or a hilited icon? No matter what I turn off or on I seem to get some additional behaviour. Like a border or the traversal border. I’m sorry that I have to bother you with this but my early days of lessons is just hidden under layers of other priorities. If all the buttons do is signal a state change that will be acted on later, I would put the following script in the group: on mouseup set the hilite of the target to not (the hilite of the target) end mouseup I would set the hiliteIcon property to get my custom icon. I would set the autohilite of the buttons to false, and just to make sure I would set the hiliteborder and hilitefill of the buttons to false, too. If I didn't want a focus border (and I never do), I would set the showfocusborder of the buttons AND of the group to false (otherwise, in Windows, the dotted line focus border shows up on the buttons anyway). If I want rollover behavior, I would use the new hoverIcon property instead of the autoArm and armedIcon property; so I'd set autoArm of the buttons to false, and I would set the armBorder and armFill of the buttons to false too, for good measure. I'd set the traversalOn of the group and the buttons to true. I'd avoid the visitedIcon unless you really have a visited state you need to convey (i.e. this button has been clicked already but it's not disabled--I guess it's a Unix thing.) If I need to carry around the state of the buttons (assuming they record states), I'd do something like: repeat with N = 1 to the number of buttons of grp states put the hilite of btn N of grp states into \ tStateArray[the short name of btn N of grp states] end repeat ...and then later: if tStateArray[meaningfulButtonName] then If it's against your religion to conflate a gui state with a program state, it's still easier and clearer when you avoid elaborate if statements, just to transfer Boolean values; that is, use: set the hilite of me to the onstate of me rather than: if the onState of me is true then set the hilite of me to true HTH, t -- Tereza Snyder Califex Software, Inc. www.califexsoftware.com -- Tereza Snyder Califex Software, Inc. www.califexsoftware.com ___ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
