dynapi-dev — List related to the current DynAPI Core development

[Dynapi-Dev] issues with 11-07 release

[Samuel, M. M <Sam...@ed...>]

I've just migrated the api files to the 11/07 release - and under Netscape 4.04
I get the following errors (where previously using DynaCore there were none).

ext/loadhtml.js line 10 EventListener is not defined
ext/loadhtml.js line 26 EventListener is not defined
api/events.js line 85 function does not always return a value }

Mike

[Dynapi-Dev] Loading HTML into layers

[Samuel, M. M <Sam...@ed...>]

I'm currently using the Dynacore loadHTML extension for loading external URL's
into a layer... However - this doesn't seem to work under Netscape 6 PR3. Has
anyone managed to kludge it or find a solution?

Thanks.

Of course I've got several other Netscape issues to contend with - but I'm just
trying to work out some issues! :)

Mike

[Dynapi-Dev] dynapi.sourceforge.net

[Robert R. <rra...@ya...>]

I put a web page up at http://dynapi.sourceforge.net.  I just wanted
people to look at it and make suggestions.  I think we need to have a
website as the homepage because the sourceforge page is not very
informative.  When we can come to a concensus about the
dynapi.sourceforge.net site, then I we can change the homepage link to
point to it.


\\Robert
-- 
rra...@ya...

Re[2]: [Dynapi-Dev] serious bug with new release

[Robert R. <rra...@ya...>]

> DynAPI.removeFromArray(this.dyndoc.allID,child,true)
> 
> and replace it with this:
> 
> delete this.dyndoc.allID[child.id]


Yep, I'll remove that. I assumed that the removeFromArray function was
working.  I also have been working on a site to put at
dynapi.sourceforge.net that I will put out there later for people to
critique.


\\Robert
-- 
rra...@ya...

[Dynapi-Dev] IE 6.0 anyone?

[Scott A. L. <sc...@sc...>]

FYI, my cross-browser brothers,

It appears that MS is getting ready to launch IE6.  They're looking for
testers, according to "Window enthusiasts" :-/

http://www.zdnet.com/zdnn/stories/news/0,4586,2650506,00.html

Re: [Dynapi-Dev] serious bug with new release

[Scott A. L. <sc...@sc...>]

Ah, I found the problem.  There are two errors in the dynlayer.js.

In both removeChild and deleteChild, locate this line:

DynAPI.removeFromArray(this.dyndoc.allID,child,true)

and replace it with this:

delete this.dyndoc.allID[child.id]

I don't know how the line got changed.  Rob, can you fix this in the
distribution?  It *is* a pretty crippling bug. It seems that
removeFromArray is not doing a proper job with associative arrays.

However, it should be noted that when using an assoc. array, it's
*always* faster and more accurate to simply do "delete array[string]"
rather than use removeFromArray.

scottandrew

[Dynapi-Dev] Question

[Benjamin L. <be...@on...>]

Hi, I am using the buttonimage in the ibs widget set.  To place the button
relative to other elements on the page, I create an inline dynlayer and then
move the object to the location of the inline dummy layer.  After lots of
experimentation, I got this to work in Internet Explorer.  However, I am
having problems with the placement in Netscape.  The following is my code:

DynAPI.onLoad=function() {
	boldButton = new IbsButtonImage()
	boldButton.setImages(DynAPI.getImage("/images/bold.gif", 20,
20),DynAPI.getImage("/images/bold_up.gif",20,20))

	lisBold = new EventListener()
	lisBold.onselect = function(e) {
		boldThis() // boldThis defined later
	}
	boldButton.addEventListener(lisBold)

	dummyBold = DynAPI.document.all["boldB"]
	dummyBold.addChild(boldButton)

	.
	.
	.
}


Html:

<span id="divRelative" style="position: relative">

<div id="boldB" style="position: absolute;left:0;top:1"></div>

</span>

I can get the buttons to appear if I add the boldButton object to
DynAPI.document but cannot add it is a child of 'dummyBold'.  Anybody know
why this would work in ie but not netscape?  Any help would be greatly
appreciated.

Benjamin Liu

Re: [Dynapi-Dev] serious bug with new release

[Scott A. L. <sc...@sc...>]

I just downloaded the lastest version, and I can't reproduce this bug
based on the code in the examples.  Mike, do you have a specific
example?

scottandrew

Re[2]: [Dynapi-Dev] Version controll or something

[Robert R. <rra...@ya...>]

I wish we were using CVS, but I have a feeling that no one would be
using it.  When we had it before, no one used it.  One good thing is
that we would not need to have beta releases (see other topic).  We
would have automatic nightly builds, since sourceforge does that for
us.

CVS is not easy to setup in Windows, but it can be done by just
following the instructions at sourceforge.  It also requires you to
instll ssh.

I think we should either use CVS or have beta releases.

\\Robert
-- 
rra...@ya...

Re: [Dynapi-Dev] Version controll or something

[Scott A. L. <sc...@sc...>]

I use WinCvs here at work...it works great but be prepared for a steep,
non-intutitive learning curve:

http://www.wincvs.org



Pascal Bestebroer wrote:
> 
> big problem here is that most of us can't get CVS working
> correctly. (yeah, yeah.. windows users :) I know there's a
> win32 client for CVS somewhere, but haven't tried it (and haven't
> actually found it, which is ofcourse contributing to the fact of
> me not trying it)
> 
> I think Robert is doing a GREAT job keeping up with all
> patch submissions here.. cheers!
> 
> Any comments/ideas on CVS or other version controlling?
> 
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
> 
> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Dougal Campbell
> Verzonden: dinsdag 7 november 2000 20:16
> Aan: Dev
> Onderwerp: Re: [Dynapi-Dev] Version controll or something
> 
> On Tue, 7 Nov 2000, Pascal Bestebroer wrote:
> 
> > I definetly like this activity on the DynAPI.. (we actually made the
> > top-something a few times at sourceforge homepage :-)
> >
> > There's just one thing: releases.. I know we all agree on the fact of
> having
> > only one release version, but maybe there should be 2 versions. One
> > fully-tested "bug-free" version, and one latest version that should be in
> > some sort of Beta fase, containing new code modifications that still need
> > some heavy testing.
> 
> Personally, I was disappointed when you turned off CVS. Of course, if
> the developers aren't using it to commit changes, I guess it doesn't do
> much good. But for other projects I track/contribute, it's really
> convenient to just do a "cvs update" and have it fetch all the recently
> modified files for me.
> 
> On the Thatware project (http://thatware.org/ or
> http://sourceforge.net/projects/thatware/), we do the usual: we use CVS
> to perform updates for bleeding edge code. Every once in a while, the
> project leader calls a feature freeze, and we can only commit bug fixes.
> Then once things seem calm, he makes a new release from the CVS and we
> open the floodgates for new (buggy :) code again.
> 
> --
> Dougal Campbell <do...@gu...> <URL:http://www.gunters.org/!dougal/>
> Professional Jack of All Trades
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] Version controll or something

[Pascal B. <pa...@dy...>]

big problem here is that most of us can't get CVS working
correctly. (yeah, yeah.. windows users :) I know there's a
win32 client for CVS somewhere, but haven't tried it (and haven't
actually found it, which is ofcourse contributing to the fact of
me not trying it)

I think Robert is doing a GREAT job keeping up with all
patch submissions here.. cheers!

Any comments/ideas on CVS or other version controlling?

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net



-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Dougal Campbell
Verzonden: dinsdag 7 november 2000 20:16
Aan: Dev
Onderwerp: Re: [Dynapi-Dev] Version controll or something


On Tue, 7 Nov 2000, Pascal Bestebroer wrote:

> I definetly like this activity on the DynAPI.. (we actually made the
> top-something a few times at sourceforge homepage :-)
>
> There's just one thing: releases.. I know we all agree on the fact of
having
> only one release version, but maybe there should be 2 versions. One
> fully-tested "bug-free" version, and one latest version that should be in
> some sort of Beta fase, containing new code modifications that still need
> some heavy testing.

Personally, I was disappointed when you turned off CVS. Of course, if
the developers aren't using it to commit changes, I guess it doesn't do
much good. But for other projects I track/contribute, it's really
convenient to just do a "cvs update" and have it fetch all the recently
modified files for me.

On the Thatware project (http://thatware.org/ or
http://sourceforge.net/projects/thatware/), we do the usual: we use CVS
to perform updates for bleeding edge code. Every once in a while, the
project leader calls a feature freeze, and we can only commit bug fixes.
Then once things seem calm, he makes a new release from the CVS and we
open the floodgates for new (buggy :) code again.

--
Dougal Campbell <do...@gu...> <URL:http://www.gunters.org/!dougal/>
Professional Jack of All Trades

_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] Version controll or something

[Dougal C. <do...@gu...>]

On Tue, 7 Nov 2000, Pascal Bestebroer wrote:

> I definetly like this activity on the DynAPI.. (we actually made the
> top-something a few times at sourceforge homepage :-)
> 
> There's just one thing: releases.. I know we all agree on the fact of having
> only one release version, but maybe there should be 2 versions. One
> fully-tested "bug-free" version, and one latest version that should be in
> some sort of Beta fase, containing new code modifications that still need
> some heavy testing.

Personally, I was disappointed when you turned off CVS. Of course, if
the developers aren't using it to commit changes, I guess it doesn't do
much good. But for other projects I track/contribute, it's really
convenient to just do a "cvs update" and have it fetch all the recently
modified files for me.

On the Thatware project (http://thatware.org/ or
http://sourceforge.net/projects/thatware/), we do the usual: we use CVS
to perform updates for bleeding edge code. Every once in a while, the
project leader calls a feature freeze, and we can only commit bug fixes.
Then once things seem calm, he makes a new release from the CVS and we
open the floodgates for new (buggy :) code again.

-- 
Dougal Campbell <do...@gu...> <URL:http://www.gunters.org/!dougal/>
Professional Jack of All Trades

[Dynapi-Dev] Version controll or something

[Pascal B. <pa...@dy...>]

I definetly like this activity on the DynAPI.. (we actually made the
top-something a few times at sourceforge homepage :-)

There's just one thing: releases.. I know we all agree on the fact of having
only one release version, but maybe there should be 2 versions. One
fully-tested "bug-free" version, and one latest version that should be in
some sort of Beta fase, containing new code modifications that still need
some heavy testing.

This way people with "real-life" projects can use the stable version, and
all others can download the latest beta update there projects and see if
everything still works (this would mostly be developers playing around with
dhtml projects)  This would give use time to give all the new code a little
time to be tested fully before the final release has it all..

Luckily we can have multiple downloads at Sourceforge.. so maybe we'll only
need to add some extra notes to releases, or use Beta in the filenames..
just some ideas ofcourse.

There have been some major changes to some of the important code (like the
events and dynlayer objects), and I'm not sure everything works ok, so to
make this the "latest" release might not be the correct name for it

Other note,  On what platforms are we testing these things?  Most of use are
using either one of these:

IE4,IE5+  WinXX/win2000/winNT
NS4.x WinXX/win2000/winNT
Mozilla (although Milestone18 sucks big time)

but how about Linux IE,NS ? Mac IE?
Is there somebody out there that has access to these platforms and is
capable of testing the DynAPI?

cya,

      Pascal Bestebroer
      pa...@dy...
      http://www.dynamic-core.net

Re: [Dynapi-Dev] serious bug with new release

[Scott A. L. <sc...@sc...>]

That warning was placed in there to prevent multiple DynLayers with
identical IDs from being added to the same DynDocument.  All DynLayers
should have unique IDs, whether assigned manually or generated by the
widget code.  This is especially important now that we are considering
going to only associative arrays in the all[] and children[]
collections.

I haven't looked at the code in a little while, but getComponent should
return a reference to the DynLayer itself, unless you overwrite it in
widget code.

So before the DynLayer is *created* by assigning it to a parent, the
return value would reference the unassigned array. After the DynLayer is
assigned, the return value should reference the all[] array of the
DynDocument that contains the DynLayer.

At least that's what *should* be happening.  I'll download the latest
package and take a look.

scottandrew



Pascal Bestebroer wrote:
> 
> "should it
> be posible to say: lyr.add(achild) then blyr.add(achild)?"
> 
> Hmm, good question, I kinda like the fact of simple calling
> one method that makes the layer remove it self from the current
> parent, and be reassigned to another parent..  but it's not very
> logicall/clean to do :)
> 
> It would fit into the "open" javascript language, but it could
> create some nasty problems in larger webapps
> 
> hmm, not really an answer :-)
> 
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
> 
> 
> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Robert Rainwater
> Verzonden: dinsdag 7 november 2000 15:37
> Aan: mi...@pr...
> Onderwerp: Re: [Dynapi-Dev] serious bug with new release
> 
> > In the addChildID() method of the DynLayer class, there is the
> > "Attempt to add ..." warning alert if you have a layer that has
> > already been added to the DynAPI.document, and then try to add that
> > same layer using the addChild() method to another layer.
> 
> The only place that layers are added to the document.all[] array is in
> addChildID().  So, if you get an alert, it should mean that the layer
> has already been attached to another layer or document.  So, should it
> be posible to say: lyr.add(achild) then blyr.add(achild)?
> 
> \\Robert
> --
> rra...@ya...
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] viewport/scrollpane files

[Dan S. <dy...@fu...>]

I've upped a zip of what I was previously working on - this won't be compatible with the current DynAPI2:

http://www.dansteinman.com/dynapi-test/dynapi2-pre2-nov00.zip

As Pascal noted he's converted LoadPanel to work with the latest, the scrollpane/scrollbar/viewport should be not too difficult to get working.  Once they are you'd be able to insert a LoadPanel into the ScrollPane and have a system that works like the Scroll2 in DynAPI1.

Dan Steinman



On Tue, Nov 07, 2000 at 05:51:34AM -0500, Rob Romanek wrote:
> 
> Dan Steinman wrote:
> 
> >  you will most likely want to use my ScrollBar/Window implementation, it's some very solid code.  Some significant changes must be done to dynapi.js in order to accomidate the way I was building my widgets.  The biggest being the removal of the "onCreate" handler altogether, and using only listeners for create and resize in the widgets.  This is what we do in WebOS because it's the only real way to implement inheritance properly with code like this.  Take a look at my ViewPort/ScrollPane files to see how it can be done in a good manner.
> 
> I've done a quick search of Dan's site and had a look at source forge but I can't find the viewport/scrollpane files. If someone knows where these are could you please point them out.
> 
> Thanks,
> 
> Rob
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] all vs. allID

[Scott A. L. <sc...@sc...>]

Yes, that's about correct.  children[] contains only the direct child
DynLayers of the DynLayer or DynDoc in question.

all[] however is only a property of the DynDocument.  It hold references
to all DynLayers within it, no matter how 'deep.'  It's similar to IE's
all[] collection, which contains references to all elements in a page
regardless of their position in the hierarchy.  DynLayers themselves
have no all[] collection, just children[].

Pascal Bestebroer wrote:
> 
> Not sure about this, but I think the difference between both arrays
> is that  the children[] array contains only the direct childs of a
> layer/dyndocument
> and the all[] array contains all layers within that layer/dyndocument
> (all levels of child objects)..
> 
> as mentioned, not sure because I don't have the code with me here.
> 
> Pascal Bestebroer
> pb...@oi...
> http://www.oibv.com
> 
> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Robert Rainwater
> Verzonden: dinsdag 7 november 2000 8:44
> Aan: Scott Andrew LePera
> Onderwerp: Re: [Dynapi-Dev] all vs. allID
> 
> > After Robert mentioned it, I can think of no good reason for maintaining
> an
> > all[] and allID[] array.  I don't think there's enough benefit to justify
> > having both.  As he suggested, the dyndocument could just as easily keep a
> > numeric count as DynLayers are added and removed.
> >
> > This would also remove potential memory leaks and speed things up a bit.
> > Unless someone has other ideas, I would suggest removing the numeric all[]
> > and replace it with allID, renaming it to all[], of course.
> 
> While it wouldn't be as easy, I think the same can be done for the
> .children array. If it were an associative array with the indexes
> being ids, it would improve the speed of deleteChild and removeChild
> since they would not have to loop through all of the children. The
> whole point of those loops is to verify the child exists. Then you
> could just say if (this.children[id]).  Maybe just add a function
> hasChildren() that returns true/false.
> 
> As far as naming, .allID should definately be renamed to .all, but of
> course that would affect the way you access inline layers, so the
> tutorials would need updating.
> 
> \\Robert
> 
> --
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

RE: [Dynapi-Dev] serious bug with new release

[Pascal B. <pa...@dy...>]

"should it
be posible to say: lyr.add(achild) then blyr.add(achild)?"


Hmm, good question, I kinda like the fact of simple calling
one method that makes the layer remove it self from the current
parent, and be reassigned to another parent..  but it's not very
logicall/clean to do :)

It would fit into the "open" javascript language, but it could
create some nasty problems in larger webapps

hmm, not really an answer :-)

Pascal Bestebroer
pa...@dy... 
http://www.dynamic-core.net 
 	


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Robert Rainwater
Verzonden: dinsdag 7 november 2000 15:37
Aan: mi...@pr...
Onderwerp: Re: [Dynapi-Dev] serious bug with new release



> In the addChildID() method of the DynLayer class, there is the
> "Attempt to add ..." warning alert if you have a layer that has
> already been added to the DynAPI.document, and then try to add that
> same layer using the addChild() method to another layer.

The only place that layers are added to the document.all[] array is in
addChildID().  So, if you get an alert, it should mean that the layer
has already been attached to another layer or document.  So, should it
be posible to say: lyr.add(achild) then blyr.add(achild)?

\\Robert
-- 
rra...@ya...


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re: [Dynapi-Dev] serious bug with new release

[Robert R. <rra...@ya...>]

> In the addChildID() method of the DynLayer class, there is the
> "Attempt to add ..." warning alert if you have a layer that has
> already been added to the DynAPI.document, and then try to add that
> same layer using the addChild() method to another layer.

The only place that layers are added to the document.all[] array is in
addChildID().  So, if you get an alert, it should mean that the layer
has already been attached to another layer or document.  So, should it
be posible to say: lyr.add(achild) then blyr.add(achild)?

\\Robert
-- 
rra...@ya...

[Dynapi-Dev] a little bug

[gyc <fs...@ci...>]

dynapi-dev，你好：

dynapi2000.11.06
dynapi/js/lib/dynapi/ext/layer.js

DynLayer.prototype.setMaxSize=function(p,noev) {
	if (!this.created && !p) return
	var w=h=0
	if (this.created) {
		w=(is.ns?this.doc.width:parseInt(this.elm.scrollWidth))
		h=(is.ns?this.doc.height:parseInt(this.elm.scrollHeight))
	}
	if (typeof(p)=='object') {
		w=(w>p.w?w:p.w)
		h=(h>p.h?h:p.h)
	} else if (typeof(p)=='boolean') noevt=p  <---noevt???Isn't it a noev???
	this.setSize(w,h,noev)
}



            gyc
            fs...@ci...

RE: [Dynapi-Dev] DynDuo now pointing to SourceForge

[Pascal B. <pb...@oi...>]

I think your right about the website, basically because Ilmaestro is being
busy as well so the download on his site could become an older version then
the one on Sourceforge (no offense Jordi :-)

The changes to DynAPI (onCreate stuff and releasemouseevents are the one I
noticed
while getting your code integrated into the new API) are, if I remember
correctly, in
the latest release.. although there's still the little code for backward
compatibility
with onCreate.

I was planning on using your servertasks, but figured that my PhP skills
weren't good
enough to do all the things I needed it for :)


Pascal Bestebroer
pb...@oi...
http://www.oibv.com


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Dan Steinman
Verzonden: dinsdag 7 november 2000 8:44
Aan: dyn...@li...
Onderwerp: [Dynapi-Dev] DynDuo now pointing to SourceForge


Sorry I've been out of the loop for a while there.  I've put a new notice on
DynDuo about DynAPI 2 and SourceForge.  So you can probably expect some more
visitors your way.  Actually the notice on the DynAPI site has been there
for a while - that's how you've been getting new visitors (primarily
developers who likely followed the Freshmeat link).

For right now I've pointed Dynduo directly at the SourceForge project page,
but this is not ideal.  One thing I could suggest is reworking IMaestro's
site to link back with SourceForge more obviously, or move it to the
http://dynapi.sourceforge.net location altogether.  Have a common download
area, and some kind of explaination of what files people need in order to
have a working DynAPI 2 - even to me it wasn't entirely clear.  The
documentation is fantastic, and the changes you've been making are great.

Pascal has some of the code I was working on a while back.  The loadpanel
worked great, and (with all due respects to IMaestro) you will most likely
want to use my ScrollBar/Window implementation, it's some very solid code.
Some significant changes must be done to dynapi.js in order to accomidate
the way I was building my widgets.  The biggest being the removal of the
"onCreate" handler altogether, and using only listeners for create and
resize in the widgets.  This is what we do in WebOS because it's the only
real way to implement inheritance properly with code like this.  Take a look
at my ViewPort/ScrollPane files to see how it can be done in a good manner.

I've noticed none of you guys really know what to do with that ServerTask
thing I wrote :)  So what I'd like to do is remove that from the DynAPI
directly - I'll maintain that code separately because I was primarily using
it as the serverside communication scheme in my
app-that-never-gets-finished, the portal thing.  I haven't worked on it in a
month, but what I'd like to do is sync it up with the latest DynAPI 2, so
that I can continue working on it without forking my JS code so much from
yours.

Anyways, I'll be keeping in tune, probably not actively developing much
directly with DynAPI but using it and making suggestions along the way.

BTW: dy...@fu... will be my email-address for messages to this
list, you can still reach me at my primary mail da...@da...

Dan Steinman

_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] serious bug with new release

[<mi...@pr...>]

There is a serious bug with the arrays in the 11-5 & 11-6 releases. 

In the addChildID() method of the DynLayer class, there is the "Attempt to add ..." warning alert if you have a layer that has already been added to the DynAPI.document, and then try to add that same layer using the addChild() method to another layer.

I did some debugging, and I am not sure if it is supposed to be this way, but when I alert the DynLayer.getComponent(), I get DynLayer.unassignedID[layername]. Is the DynLayer component supposed to be referenced by the unassigned array?

This is a pretty serious bug, and is relevant to the array discussions currently being posted.

Does anyone have any ideas?

--proteanman

RE: [Dynapi-Dev] viewport/scrollpane files

[Pascal B. <pb...@oi...>]

Probably my fault, I did supply the loadpanel, but not the
viewport/scrollpane
code .. I haven't checked if they were compatible with DynAPI2 so I didn't
think
it would be smart uploading them.

I'll post it tonight (when I get home) or maybe Dan will post it himself
before me :)

greets,

Pascal Bestebroer
pb...@oi...
http://www.oibv.com


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Rob Romanek
Verzonden: dinsdag 7 november 2000 12:09
Aan: dyn...@li...
Onderwerp: [Dynapi-Dev] viewport/scrollpane files



Dan Steinman wrote:

>  you will most likely want to use my ScrollBar/Window implementation, it's
some very solid code.  Some significant changes must be done to dynapi.js in
order to accomidate the way I was building my widgets.  The biggest being
the removal of the "onCreate" handler altogether, and using only listeners
for create and resize in the widgets.  This is what we do in WebOS because
it's the only real way to implement inheritance properly with code like
this.  Take a look at my ViewPort/ScrollPane files to see how it can be done
in a good manner.

I've done a quick search of Dan's site and had a look at source forge but I
can't find the viewport/scrollpane files. If someone knows where these are
could you please point them out.

Thanks,

Rob


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] viewport/scrollpane files

[Rob R. <ro...@ma...>]

Dan Steinman wrote:

>  you will most likely want to use my ScrollBar/Window implementation, it's some very solid code.  Some significant changes must be done to dynapi.js in order to accomidate the way I was building my widgets.  The biggest being the removal of the "onCreate" handler altogether, and using only listeners for create and resize in the widgets.  This is what we do in WebOS because it's the only real way to implement inheritance properly with code like this.  Take a look at my ViewPort/ScrollPane files to see how it can be done in a good manner.

I've done a quick search of Dan's site and had a look at source forge but I can't find the viewport/scrollpane files. If someone knows where these are could you please point them out.

Thanks,

Rob

RE: [Dynapi-Dev] all vs. allID

[Pascal B. <pb...@oi...>]

Not sure about this, but I think the difference between both arrays
is that  the children[] array contains only the direct childs of a
layer/dyndocument
and the all[] array contains all layers within that layer/dyndocument
(all levels of child objects)..

as mentioned, not sure because I don't have the code with me here.


Pascal Bestebroer
pb...@oi...
http://www.oibv.com


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Robert Rainwater
Verzonden: dinsdag 7 november 2000 8:44
Aan: Scott Andrew LePera
Onderwerp: Re: [Dynapi-Dev] all vs. allID



> After Robert mentioned it, I can think of no good reason for maintaining
an
> all[] and allID[] array.  I don't think there's enough benefit to justify
> having both.  As he suggested, the dyndocument could just as easily keep a
> numeric count as DynLayers are added and removed.
>
> This would also remove potential memory leaks and speed things up a bit.
> Unless someone has other ideas, I would suggest removing the numeric all[]
> and replace it with allID, renaming it to all[], of course.

While it wouldn't be as easy, I think the same can be done for the
.children array. If it were an associative array with the indexes
being ids, it would improve the speed of deleteChild and removeChild
since they would not have to loop through all of the children. The
whole point of those loops is to verify the child exists. Then you
could just say if (this.children[id]).  Maybe just add a function
hasChildren() that returns true/false.

As far as naming, .allID should definately be renamed to .all, but of
course that would affect the way you access inline layers, so the
tutorials would need updating.


\\Robert

--


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] DynDuo now pointing to SourceForge

[Dan S. <dy...@fu...>]

Sorry I've been out of the loop for a while there.  I've put a new notice on DynDuo about DynAPI 2 and SourceForge.  So you can probably expect some more visitors your way.  Actually the notice on the DynAPI site has been there for a while - that's how you've been getting new visitors (primarily developers who likely followed the Freshmeat link).

For right now I've pointed Dynduo directly at the SourceForge project page, but this is not ideal.  One thing I could suggest is reworking IMaestro's site to link back with SourceForge more obviously, or move it to the http://dynapi.sourceforge.net location altogether.  Have a common download area, and some kind of explaination of what files people need in order to have a working DynAPI 2 - even to me it wasn't entirely clear.  The documentation is fantastic, and the changes you've been making are great.

Pascal has some of the code I was working on a while back.  The loadpanel worked great, and (with all due respects to IMaestro) you will most likely want to use my ScrollBar/Window implementation, it's some very solid code.  Some significant changes must be done to dynapi.js in order to accomidate the way I was building my widgets.  The biggest being the removal of the "onCreate" handler altogether, and using only listeners for create and resize in the widgets.  This is what we do in WebOS because it's the only real way to implement inheritance properly with code like this.  Take a look at my ViewPort/ScrollPane files to see how it can be done in a good manner.

I've noticed none of you guys really know what to do with that ServerTask thing I wrote :)  So what I'd like to do is remove that from the DynAPI directly - I'll maintain that code separately because I was primarily using it as the serverside communication scheme in my app-that-never-gets-finished, the portal thing.  I haven't worked on it in a month, but what I'd like to do is sync it up with the latest DynAPI 2, so that I can continue working on it without forking my JS code so much from yours.

Anyways, I'll be keeping in tune, probably not actively developing much directly with DynAPI but using it and making suggestions along the way.

BTW: dy...@fu... will be my email-address for messages to this list, you can still reach me at my primary mail da...@da...

Dan Steinman