I have that window manager the does all those things. The only thing you
need to write for it is a GUI.
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
it may sound like a broken records but I see no problem with forcing all
browsers to play on a level playing field. Then, from there, we can really
start to build cross-browser functionality.
Doug Melvin wrote:
> I don't think "crippling" is the right attitude (imho)
> I am a firm believer that
Bugs item #408289, was updated on 2001-03-13 11:15
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=408289&group_id=5757
Category: Core - Widgets
Group: Feature Request
Status: Open
Priority: 5
Submitted By: Colin Johnson (therealevilted)
Assigned to: Nobo
Bugs item #409601, was updated on 2001-03-18 14:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=409601&group_id=5757
Category: Core API
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Bugs item #409601, was updated on 2001-03-18 14:30
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=409601&group_id=5757
Category: Core API
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
A good idea.
Maybe something to consider when designing the layout manager (whenever that
happens.. :-)
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, March 18, 2001 11:44 AM
Subject: [Dynapi-Dev] [ dynapi-Patches-409569 ] Z-index: bringToFront,
sendTo
I don't think "crippling" is the right attitude (imho)
I am a firm believer that an APP should be able to 'devolve' a little
to support other browsers..
But I see no reason why the 85% of user using IE
shouldn't get to take full advantage of their browser's capabilities..
- Original Message --
Patches item #409569, was updated on 2001-03-18 11:44
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305757&aid=409569&group_id=5757
Category: DynAPI-Layer
Group: None
Status: Open
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (n
Patches item #409543, was updated on 2001-03-18 08:01
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305757&aid=409543&group_id=5757
Category: DynAPI-Event
Group: None
Status: Open
Priority: 5
Submitted By: Michael Pemberton (mpember)
Assigned to: Nobody/Anonymous
I've been looking at the problem with the layer position being stuffed
in the dragdrop example.
It is a problem with the docListener.mousemove method.
The following code change needs to be made. This way, the layer
position remains the same on the screen when you move it from a layer to
the docu
Patches item #409538, was updated on 2001-03-18 07:27
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305757&aid=409538&group_id=5757
Category: DynAPI-Widget
Group: None
Status: Open
Priority: 5
Submitted By: Richard Bennett (richard_bennett)
Assigned to: Nobody/Ano
if you wanted to, you could add a mouse out / over listener that changes
the
focus pointer to 'none'. then, alter my code to listen for the value of
'none'
and terminate the event there. that way it will work in NS4.
I would prefer if we got all browsers working in a standard manner and
built
f
Again the list software messed it up and I am only seeing your email now. My
point is that we can get it to work in NS.
No big deal.
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
As i've explained earlier, it is simply a metter of setting the .focus value to
null when the mousedown is triggered.
Pascal Bestebroer wrote:
> seeing that NS4 is not supporting this, if we simply can't make it work, we
> should make sure it is switched off in IE by default, with the option of
seeing that NS4 is not supporting this, if we simply can't make it work, we
should make sure it is switched off in IE by default, with the option of
turning it on (everyone's happy :)
the API should work the same cross-browser as much as possible..
I can't consider this crippling a browser.
we c
then just place a line of code in the button that null's the focus value.
on the other side, look at a scrollbar on any os, it will stop responding to
mouse movements no matter where you release the mouse button.
Eytan Heidingsfeld wrote:
> There was already a mention of such a real world examp
There was already a mention of such a real world example. Take a button for
instance, the button code should only be executed if the mouse-up was over a
button. (Open up any App on any OS and try pressing down on a button moving
off it and realeasing).
8an
__
I didn't mean to be so hard but I am just a bit ticked off that my code
inclusion was being stoned without any actual example of why it would need to be
excuded.
This has been happening on this list for a while (I'm talking in general, not
just about my code) and it has started to get on my nerve
For the first time someone agress with me and you stone him? You evil evil
being!!
I'm sure he can come up with ideas I'm to busy working right now but since
(yes me rambling about this again) this is an API we are supposed to do what
is right and not what is more frequently used.
8an
_
then show me an example of where your require a mouseup event to be triggered in
a separate place to the mousedown event.
then, show me where you can have a page that requires this in more places than
it doesn't.
if you can't. simply do as I said previously and clear the .focus pointer to
null
20 matches
Mail list logo
