Which makes it slightly slower (but I'm not compaining)
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
As I have mentioned (more then once) the delete operator works but
onlytested it on actual objects. Not DHTML components(layers,divs,nodes)
forthose you have a whole new set of rules. So we need to find out how to
freeactual elements.8an
man, now your gonna get it :)
leave the inheriting model alone!
serious though, currently widgets really inherit from the dynlayer, so that
all dynlayer methods are available without any extra code (or memory)
if you make it a property of the widget, all these things are gone and you
would need
It HURTS!
My My The Rocks fell like rain!!
(And Feb 24th is even my birthday ;-)
There will be no difference in memory if you place it as an object but it is
just better programming. Straight out! The problem is that you think of
DynLayer as a widget instead of an interface remember it is Dyn - AP
As much as I liked DynAPI 1, I don't want to go back to those days :)
I think the widget model as it is now, is much more extensible than by
not using any type of inheriting.
--
// Robert Rainwater
On 2/25/2001, 3:48:41 AM EST, Pascal wrote about "[Dynapi-Dev] a few hours for only 2
lines of
I removed the addChildID from dynlayer.js. The document.all[] id's
are now set in assignChildren. It seems that assignChildren was
stepping through the children right after addChildID did the same, so
I just put the code in assignChildren and removed addChildID. May not
be much of an improveme
I decided to tackle the more DHTML side of
it.
I have also decided that all tests should be per
browser since they are all different.
IE 5.0 great news.
Creating 1500 layers raises mem usg to 10 MB(From
8+-)
Deletion down to 9 MB!
8an
Try any of the button examples or the scrollpane example. No events
are fired when directly over an image. I'm using the latest code from
CVS.
I thought this had been fixed before?
--
// Robert Rainwater
On 2/24/2001, 11:37:55 PM EST, Doug wrote about "[Dynapi-Dev] [ dynapi-Bugs-404007 ]
E
And see the API part, this means not just for making things work
cross-browser, but also make the underlying code transparent and as easy to
use as possible.
So the difference:
myWidget.moveTo(50,50)
or
myWidget.DynLayer.moveTo(50,50)
would
1. add more code in general
2. not as transparent a
uhm.. just in case: sorry :)
Not sure if I broke anything, but that's why people should now test the CVS
code as much as possible
I did alot of if statement changes, and other optimisations so these might
have caused problems.
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.dynamic-core.net
>
Yes I still want to implement it, but it does require some time to split up
the needed code, and didn't find the time for it yesterday.
I do believe it should be done before any new release, because we already
have a heavily changed code now which might cause bugs so adding this
potential-bug-tra
A wrapper function would be added to myWidget that would look like this:
myWidget.prototype.moveTo = function(x,y){
this.dynlayer.moveto(x,y);
}
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-d
extra code (size is also an issue with javascript)
to be rude: these things have all been discussed many times in the last
year.. and we (including Dan back then) decided that this was just the most
straight forward way of doing the inheriting (and widgets SHOULD inherit
from dynlayer for should
Artifact #404007, was updated on 2001-02-24 16:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=404007&group_id=5757
Category: Core API
Group: None
Status: Open
Priority: 6
Submitted By: Robert Rainwater
Assigned to: Pascal Bestebroer
Summary: Events in
Artifact #404007, was updated on 2001-02-24 16:07
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=404007&group_id=5757
Category: Core API
Group: None
Status: Closed
Priority: 6
Submitted By: Robert Rainwater
Assigned to: Pascal Bestebroer
Summary: Events
k, fixed it
Pascal Bestebroer
[EMAIL PROTECTED]
http://www.dynamic-core.net
> -Oorspronkelijk bericht-
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Namens Pascal Bestebroer
> Verzonden: zondag 25 februari 2001 11:21
> Aan: [EMAIL PROTECTED]
> Onderwerp: RE: Re[2]: [Dynapi-Dev] [
not sure how we can maintain it..
currently we have one release version, and one in CVS which is just the
working code.
No real versions numbers (just dates) are added..
having two versions is alot to maintain (I know :) but if you can come up
with a good idea, attach it to a rock and throw it.
Give me a break!
Not meaning to sound rude: the over head of those bytes is the least of our
problems and anyway since they are part of an object (not element) there
isn't even a leak!
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sour
over head of those bytes IS a problem.. a webapplication or very enhanced
website would
have ALOT of extra code going on, so all files would require much more.
I dont see what the big improvement would be.. you still have a DynLayer to
deal with.
The main problem is that your doing alot of worka
And even greater news from the front
15k divs bump the mem to 20MB
freeing brings us back to 9MB
Yippy
8an
The problem is actualy two:
* Correct programming
Just what it sounds like. Imagine in windows all components would inherit
from canvas
* Eaisier to write widgets.
For instance a pop up menu (what a cool idea ;-) because you don't know
where on the page you are and you might want the pop up menu t
> * Correct programming
> Just what it sounds like. Imagine in windows all components would inherit
> from canvas
look at delphi : TComponent (that's our DynLayer) the base object of all
components/widgets.
> * Eaisier to write widgets.
> For instance a pop up menu (what a cool idea ;-) beca
No,
Delphi TComponent (been reading about this because of the Kylix) is a basic
component that wraps the calls to the API.
I don't care if we make a TComponent or TWidget but I just perfer this over
using the DynLayer itself.
8an
___
Dynapi-Dev maili
DynLayer IS the root component (that's what I've been trying to say)
Every widget needs the graphical functionality of a DynLayer, that's why it
IS the base object.
Ofcourse TComponent is Delphi only, because Windows internally probably
doesn't have anything like it.. just graphics functions to
Ok.
You know what.
I can see this.
U win. (About the DynLayer not being a property)
k?
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
Not having much luck with removeChild in
NN6
and NN4 seems like a lossed cause. Even if I browse
non DHTML pages it leaks!
8an
I've combined the different methods of stopping IE from displaying
context menus and selecting text into the following lines of code. They
should be placed just before the "return evt.browserReturn;" line.
if (is.ie5) {
if (evt.type=='mouseup' && evt.button==3)
dyndoc.doc.oncontextmenu=(evt
I'm sorry if I'm late on the topic but it sux being 12 hours behind on
all of these discussions.
The API IS standalone. By itself it has NO visual components. If you
want a root object on which to base your widgets, use the base JS object
Object. This is what the DynLayer istelf in inhereting
Ok.
Now to another discussion that has to do with the previous one.
What about creating an Application object.
You don't have to use it. It will be optional but will take care of stuff
like focus.
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http:
this can be done again by just extending an Object.
it is actually something i'm thinking of looking into for use with my dynform
objects.
Eytan Heidingsfeld wrote:
> Ok.
> Now to another discussion that has to do with the previous one.
> What about creating an Application object.
> You don't h
Are your dynform for forms as in vb delphi forms (windows) or as in HTML
forms?
Cause I was also going to devlop a vb delphi one. I'd love to see urs.
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-
Artifact #223612, was updated on 2000-11-27 10:14
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105757&aid=223612&group_id=5757
Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Joshua Hancik
Assigned to: Nobody/Anonymous
Summary: No mouseEvents in
I'm trying to write a widget your way and am getting elm.style is undefined
does anyone know why this would happen or do I have to track it?
8an
___
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
What made you think that MS has a JIT for JScript? Personally I thought this
was one of the good news about .Net and JScript.Net. (Getting the same
performance as from all other languages.)
IE3+ has been using MS JVM which uses JIT but this does not mean that
JScript benefits from this?
Any proo
The only JIT (Just-in-time) compiler I've ever heard of was for Java.
But, I guess it MS could have one for JScript, but I've never heard of
it.
--
// Robert Rainwater
On 2/25/2001, 2:57:17 PM EST, Erik wrote about "[Dynapi-Dev] JIT JavaScript (was My JS
Optimization Site)":
> What made you
Heh, I was just about to post this as something similar was suggested from others.
Well, I guess it might add to the current turns as-is...
---
I think that there's at least one occation when its useful of using an object other
than simply the dynlayer OR dyndocument - managers. With managers I
I most whole heartedly agree.
The inheriting model makes so much of what I do possible.
Withou one you loose the most integral part of the API.
(IMHO of course)
Dogu
- Original Message -
From: "Robert Rainwater" <[EMAIL PROTECTED]>
To: "DynAPI Development List" <[EMAIL PROTECTED]>
Sent:
um, that would make two function calls instead of one..
With an interpreted language that can add up over several objects to
noticeably slow down the whole application.
- Original Message -
From: "Eytan Heidingsfeld" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, February 25,
How about a compramise?
A SlimDynLayer?
it would have addchild, moveto, setsize and such..
but would not have sethtml,setcontent,getcontentwidth.. ect..
Just a super-basic object that can be used for 'lightweight' widgets
- Original Message -
From: "Pascal Bestebroer" <[EMAIL PROTECTED]>
I think we can remove the flagprecreate and flagdelete methods. If
flagprecreate is put into the createelement, you will notice a slight
improvement in the time to create many nested layers. Unless there are
any compelling reasons to keep these methods, I think they can be
placed directly inside
I thought resizing in NS was fixed
again?
Is there still a problem with
dynimage?
this is so frusterating.
---Outgoing mail is certified Virus Free by
AVG Free EditionDownload at: http://www.grisoft.com/html/us_index.cfmChecked
by AVG anti-virus system (http://www.grisoft.com).Version: 6.0
traced resizing in ns.
followed it back to setHTML in
dynimage,
traced it further back the the onresize call in the
dynimage itself.
fixed if by modifiying the onresize for DynImage
tot he foloowing:
setTimeout("DynAPI.document.all['"+o.id+"'].setImage(DynAPI.document.all['"+o.id+"'].img,t
Jeff wrote:
>
> Whew! Go away for a day and the messages pile up!
>
> Raides J. - I was under the impression that this (JIT) was essentially
> the case for both browsers, but I could be mistaken. The following is
> from the Netscape JavaScript 1.3 reference, describing a function as
> opposed to
Erik Arvidsson wrote:
>
> What made you think that MS has a JIT for JScript? Personally I thought this
> was one of the good news about .Net and JScript.Net. (Getting the same
> performance as from all other languages.)
>
> IE3+ has been using MS JVM which uses JIT but this does not mean that
> J
Hey Doug,
The problem/solution I posted on the help list
Saturday was regarding the window resizing in NS4.xx
when a dynimage was used in a layer. Someone had
posted some example code and it was similar to a
problem I was having.
There was definitely a problem as the dynimage was
causing a fa
check that you are using the oncreate event to access the elements on the
layer. the browser layer object is not created at the time yoyur are trying to
access it.
also, move this type of questions to the help list.
Eytan Heidingsfeld wrote:
> I'm trying to write a widget your way and am getti
check that you are using the oncreate event to access the elements on
the
layer. the browser layer object is not created at the time yoyur are
trying to
access it.
also, move this type of questions to the help list.
Eytan Heidingsfeld wrote:
> I'm trying to write a widget your way and am getti
I can only guess that the events problems are due to the .lyrobj only
being set in the initial creation stage.
if might be worth testing if there are any images added in the setHTML
method and then updating the .lyrorj for the newly added images.
If I'm wrong, rock my world. If not, anyone got
Yep, usually something like:
if (!this.created) return;
If you look in some of the included widgets you will see these checks
--
// Robert Rainwater
--
DynAPI Homepage: http://dynapi.sourceforge.net/
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
On Sunday, February 25, 2001 8:1
that .lyrobj code is back in (did it yesterday) so images should
trigger the events normally again. (CVS code)
Pascal Bestebroer ([EMAIL PROTECTED])
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com
> -Oorspronkelijk bericht-
> Van: [EMAIL PROTECTED]
> [mailto:[EM
50 matches
Mail list logo
