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

Re: [Dynapi-Dev] (no subject)

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

I like that idea, and it seems to work.  I would propose some standard
syntax:

function Widget() {
  this.superClass = DynLayer
  this.superClass()
  ...
}

I think that's easier to understand than "this.DynLayer=DynLayer"...what
DynLayer? :-)












-----Original Message-----
From: Pascal Bestebroer <pa...@dy...>
To: dyn...@li... <dyn...@li...>
Date: Sunday, October 29, 2000 4:49 AM
Subject: RE: [Dynapi-Dev] (no subject)


>I think there's another way of solving this..  By slightly changing the
>way widgets are created (still using the same inheriting methods)
>
>here's an example:
>
>
>function CoreButton(x,y,w,h,caption,flat) {
> this.DynLayer = DynLayer
> this.DynLayer()
>
> this.id = "CoreButton"+(CoreButton.Count++)
>
> this.moveTo(x||0,y||0)
> this.setSize(w||128,h||36)
>
> this.caption=caption||''
>
> this.lcaption=new DynLayer(null,2,2)
> this.levents=new DynLayer(null,0,0)
>
> this.lcaption.setVisible(true)
> this.levents.setVisible(true)
>
> this.setFlat(flat||false)
> this.setVisible(true)
>
> this.style=new CoreStyle()
>
> this.children=[]
>
> return this
>}
>CoreButton.Count=0
>CoreButton.prototype = new DynLayer()
>
>The first lines in the constructor show the main change, I actually think
>somebody
>else had already mentioned this a while back but I didn't look at it then
:(
>
>This is actually the way Netscape is talking about creating objects on the
>tutorial sites.
>
>I think this solves the problem with the children array, so that no changes
>are needed to
>the dynlayer constructor. The widget will still be an "enhancded" dynlayer.
>
>I've also been working on benchmark / test code and I'll try to post it so
>that people
>can look at it and run some tests in other browsers.
>
>Pascal Bestebroer
>pa...@dy...
>http://www.dynamic-core.net
>
>
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] (no subject)

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

I think there's another way of solving this..  By slightly changing the
way widgets are created (still using the same inheriting methods)

here's an example:


function CoreButton(x,y,w,h,caption,flat) {
	this.DynLayer = DynLayer
	this.DynLayer()

	this.id = "CoreButton"+(CoreButton.Count++)

	this.moveTo(x||0,y||0)
	this.setSize(w||128,h||36)

	this.caption=caption||''

	this.lcaption=new DynLayer(null,2,2)
	this.levents=new DynLayer(null,0,0)

	this.lcaption.setVisible(true)
	this.levents.setVisible(true)

	this.setFlat(flat||false)
	this.setVisible(true)

	this.style=new CoreStyle()

	this.children=[]

	return this
}
CoreButton.Count=0
CoreButton.prototype = new DynLayer()

The first lines in the constructor show the main change, I actually think
somebody
else had already mentioned this a while back but I didn't look at it then :(

This is actually the way Netscape is talking about creating objects on the
tutorial sites.

I think this solves the problem with the children array, so that no changes
are needed to
the dynlayer constructor. The widget will still be an "enhancded" dynlayer.

I've also been working on benchmark / test code and I'll try to post it so
that people
can look at it and run some tests in other browsers.

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

[Dynapi-Dev] IE browser versions in Windows

[¤¤¤¤¤ ¤¤¤¤¤ <qu...@ya...>]

Hey.. 
This is not really a dynAPI related question but then
again,I guess it is ... :) 
The problem is concurrent use of different IE browsers
under windows. 
Now you can use 4 and 5 together (4 in a compatability
mode) but what about 5.5? 
I would like to be able to use all three versions at
the "same" time, and possibly future versions aswell.
I know this is a well known problem , and at work I
have it solved by using an extra test computer with IE
5.5. But that's not really an optimal solution. There
has to be another way. For instance, maybe there are
standalone versions of the browsers somewhere...
Read about that somewhere... but I haven't been able
to find such progs.
Anyone got a clue?

__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf!  It's FREE.
http://im.yahoo.com/

Re[2]: [Dynapi-Dev] (no subject)

[Robert R. <rai...@us...>]

I added a hasChildren method to the dynlayer and dyndocument to make
it easier to check for children, since there are two different states
that the children array can have that mean there are no children.

DynLayer.prototype.hasChildren=function() { return !this.children||!this.children.length?false:true }

DynDocument.prototype.hasChildren=function() { return !this.children||!this.children.length?false:true }


Later,
Robert <rai...@us...>

> Yes, a boolean could do the same trick.  Maybe removeChild/deleteChild can
> set it to true/false if the length becomes zero.
> 
> My point is that when you define an object's prototype structure with
> another object, as in WidgetX, all of the properties of that base DynLayer
> instance are shared with each Widget.
> 
> Widget.prototype=new DynLayer() <-- Widget.prototype is a new DynLayer
> *instance*
> 
> This is generally okay in DynAPI2 because the shared properties are
> eventually overwritten with unique ones.
> 
> For example, all WidgetX model widgets share the *same* css, elm and doc
> object when first constructed.  But when you add them to a parent object,
> the assignElement method overwrites them with *unique* values.
> 
> But children[] is never overwritten anywhere, so it remains a reference to
> the children array of the shared base DynLayer instance. So we either have
> to 1) always remember to assign it "manually" in our widget code, or 2) find
> a better place in the DynLayer code to assign it to ensure it is unique.
> 
> I'm not trying to undermine the WidgetX model, because it's an easy way to
> achieve a sort of inheritance, but this issue needs to be addressed.  Who
> knows what kind of memory leaks this may cause in the long run:
> 
> Widget1.prototype = new DynLayer();
> Widget2.prototype = new Widget1();
> Widget3.prototype = new Widget2(); etc.
> 
> scottandrew
> 
> 
> 
> -----Original Message-----
> From: Robert Rainwater <rai...@us...>
> To: Scott Andrew LePera <dyn...@li...>
> Date: Saturday, October 28, 2000 2:13 PM
> Subject: Re: [Dynapi-Dev] (no subject)

Re: [Dynapi-Dev] (no subject)

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

Yes, a boolean could do the same trick.  Maybe removeChild/deleteChild can
set it to true/false if the length becomes zero.

My point is that when you define an object's prototype structure with
another object, as in WidgetX, all of the properties of that base DynLayer
instance are shared with each Widget.

Widget.prototype=new DynLayer() <-- Widget.prototype is a new DynLayer
*instance*

This is generally okay in DynAPI2 because the shared properties are
eventually overwritten with unique ones.

For example, all WidgetX model widgets share the *same* css, elm and doc
object when first constructed.  But when you add them to a parent object,
the assignElement method overwrites them with *unique* values.

But children[] is never overwritten anywhere, so it remains a reference to
the children array of the shared base DynLayer instance. So we either have
to 1) always remember to assign it "manually" in our widget code, or 2) find
a better place in the DynLayer code to assign it to ensure it is unique.

I'm not trying to undermine the WidgetX model, because it's an easy way to
achieve a sort of inheritance, but this issue needs to be addressed.  Who
knows what kind of memory leaks this may cause in the long run:

Widget1.prototype = new DynLayer();
Widget2.prototype = new Widget1();
Widget3.prototype = new Widget2(); etc.

scottandrew



-----Original Message-----
From: Robert Rainwater <rai...@us...>
To: Scott Andrew LePera <dyn...@li...>
Date: Saturday, October 28, 2000 2:13 PM
Subject: Re: [Dynapi-Dev] (no subject)


>
>There's also a bit of inconsistency with making the children array
>null.   Because once you remove all the children, the array is not
>null, but has a length of 0.  So, in your widget, you will have to
>check for a null array and a array of length 0.  I don't understand
>why the array can't be initialized to an empty array.
>
>
>Later,
>Robert <rai...@us...>
>
>> I think I've found a fix for the problem with children arrays being
shared
>> between widgets made with the widgetX  model.
>>
>> The problem:
>>
>> Widget.prototype = new DynLayer()
>>
>> When this is done, the properties of the base DynLayer are *shared* with
>> every Widget made with the constructor.
>>
>> Most of these shared properties are reassigned to unique ones when
>> createElement is called on the Widget.  However, the children array is
not,
>> and it gives the effect that all Widgets share the same children array.
>>
>> So I've posted a patch for DynLayer and DynDocument that assigns the
>> this.children array only when you use addChild.  DynLayer-based widgets
>> won't have a children array until you add at least one child.
>>
>> I also made changes to removeChild, removeAllChildren, etc. that check
for
>> the existence of the child array before proceeding.
>>
>> This should ensure that the children array is a unique object for each
>> widget, and not the common one in the Widget prototype.  Then you can
safely
>> use WidgetX to simulate inheritance without the shared-properties
problem.
>>
>> The only consideration is if you build a widget that manipulates the
>> children array, you should test it it exists first (it's initially set to
>> null until you use addChild).
>>
>> I've only tested it on a few IBS and GUI widgets, but it seems to work
>> across the board.  I've posted the patch for review.
>>
>> scottandrew
>>
>>
>>
>>
>>
>>
>> ------
>> Scott Andrew LePera
>> DHTML / Scripting / CGI and other neat stuff
>> sc...@sc...
>> http://www.scottandrew.com
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] (no subject)

[Robert R. <rai...@us...>]

There's also a bit of inconsistency with making the children array
null.   Because once you remove all the children, the array is not
null, but has a length of 0.  So, in your widget, you will have to
check for a null array and a array of length 0.  I don't understand
why the array can't be initialized to an empty array.


Later,
Robert <rai...@us...>

> I think I've found a fix for the problem with children arrays being shared
> between widgets made with the widgetX  model.
> 
> The problem:
> 
> Widget.prototype = new DynLayer()
> 
> When this is done, the properties of the base DynLayer are *shared* with
> every Widget made with the constructor.
> 
> Most of these shared properties are reassigned to unique ones when
> createElement is called on the Widget.  However, the children array is not,
> and it gives the effect that all Widgets share the same children array.
> 
> So I've posted a patch for DynLayer and DynDocument that assigns the
> this.children array only when you use addChild.  DynLayer-based widgets
> won't have a children array until you add at least one child.
> 
> I also made changes to removeChild, removeAllChildren, etc. that check for
> the existence of the child array before proceeding.
> 
> This should ensure that the children array is a unique object for each
> widget, and not the common one in the Widget prototype.  Then you can safely
> use WidgetX to simulate inheritance without the shared-properties problem.
> 
> The only consideration is if you build a widget that manipulates the
> children array, you should test it it exists first (it's initially set to
> null until you use addChild).
> 
> I've only tested it on a few IBS and GUI widgets, but it seems to work
> across the board.  I've posted the patch for review.
> 
> scottandrew
> 
> 
> 
> 
> 
> 
> ------
> Scott Andrew LePera
> DHTML / Scripting / CGI and other neat stuff
> sc...@sc...
> http://www.scottandrew.com

Re: [Dynapi-Dev] (no subject)

[Robert R. <rai...@us...>]

If we choose to set the children array to null, then maybe we should
have an function hasChildren() that returns a boolean.

Later,
Robert <rai...@us...>

> So I've posted a patch for DynLayer and DynDocument that assigns the
> this.children array only when you use addChild.  DynLayer-based widgets
> won't have a children array until you add at least one child.
> 
> I also made changes to removeChild, removeAllChildren, etc. that check for
> the existence of the child array before proceeding.
> 
> This should ensure that the children array is a unique object for each
> widget, and not the common one in the Widget prototype.  Then you can safely
> use WidgetX to simulate inheritance without the shared-properties problem.
> 
> The only consideration is if you build a widget that manipulates the
> children array, you should test it it exists first (it's initially set to
> null until you use addChild).
> 
> I've only tested it on a few IBS and GUI widgets, but it seems to work
> across the board.  I've posted the patch for review.
> 
> scottandrew

[Dynapi-Dev] (no subject)

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

I think I've found a fix for the problem with children arrays being shared
between widgets made with the widgetX  model.

The problem:

Widget.prototype = new DynLayer()

When this is done, the properties of the base DynLayer are *shared* with
every Widget made with the constructor.

Most of these shared properties are reassigned to unique ones when
createElement is called on the Widget.  However, the children array is not,
and it gives the effect that all Widgets share the same children array.

So I've posted a patch for DynLayer and DynDocument that assigns the
this.children array only when you use addChild.  DynLayer-based widgets
won't have a children array until you add at least one child.

I also made changes to removeChild, removeAllChildren, etc. that check for
the existence of the child array before proceeding.

This should ensure that the children array is a unique object for each
widget, and not the common one in the Widget prototype.  Then you can safely
use WidgetX to simulate inheritance without the shared-properties problem.

The only consideration is if you build a widget that manipulates the
children array, you should test it it exists first (it's initially set to
null until you use addChild).

I've only tested it on a few IBS and GUI widgets, but it seems to work
across the board.  I've posted the patch for review.

scottandrew






------
Scott Andrew LePera
DHTML / Scripting / CGI and other neat stuff
sc...@sc...
http://www.scottandrew.com

Re: [Dynapi-Dev] Template center

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

This is very, very cool.  It's going to save me a lot of time :-)

My only tiny criticism (and this is more from a usability standpoint) is
that the text color you've chosen for the code samples is a little pale and
hard to read against the white screen.  I have to squint to see it.

Otherwise, fantastic work!

  -----Original Message-----
  From: Jordan Lewinski <jo...@ex...>
  To: dyn...@li... <dyn...@li...>
  Date: Saturday, October 28, 2000 5:38 AM
  Subject: [Dynapi-Dev] Template center


  Hi there

  located at http://www.extopia.co.il/dynapi/

  i've opend the first draft of the common API template center.
  available now is the widget documentation template for the distribution.
  this should supplement any DB created for the documentation.

  please send me comment so i can implement the asap, so people can start
  using common templates.

  Jordan Lewinski

[Dynapi-Dev] Template center

[Jordan L. <jo...@ex...>]

Hi there

located at http://www.extopia.co.il/dynapi/

i've opend the first draft of the common API template center.
available now is the widget documentation template for the distribution.
this should supplement any DB created for the documentation.

please send me comment so i can implement the asap, so people can start
using common templates.

Jordan Lewinski

[Dynapi-Dev] Re: children[] bug

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

If fixed the removefromArray by changing:

delete array[array.length - 1]

to

array.length -= 1

This was causing an error with deleting.  I also updated the distribution patch at sourceforge.

Robert

-- 
Email: <mailto:rra...@ya...>

[Dynapi-Dev] children[] bug

[Robert R. <rai...@us...>]

I noticed a bug that seems to have popped up with Scott's new array
handling of the id's.  When you do a deletefromparent, the children
array length does not decrement by 1, it just stays the same.  If you
look at the core.api.delete.html file in the patch distribution I
posted, you will see the error.

Later,
Robert <rai...@us...>

[Dynapi-Dev] DynAPI Release Candidate

[Robert R. <rai...@us...>]

I've uploaded a release candidate for the next release in the patches
section.

You can download it here: http://sourceforge.net/patch/index.php?func=detailpatch&patch_id=102140&group_id=5757

It is a zip file, so you may have to change the default extension when
you download it.  Please let the list know of bugs/changes/etc that
can be made to it.

Later,
Robert <rai...@us...>

[Dynapi-Dev] Documentation!

[Jannon F. <ja...@CS...>]

Man, guess I shouldn't have slept in...The documentation discussion is hot.

Anyway, so you can take a look at what I was talking about at:
http://63.193.192.5:8080/dynapi_doc/package_list.jsp

This is just a stripped down, no-frills version that I think we can use to
get all the information in there.  We can work on display later.  You can't
actually edit or add anything yet (I'll finish those pages today)  Then I
figure we can get everything into the DB and then and someone else can write
a display interface in php if they want...or maybe I'll learn it.

Once I get the entry/edit pages up, with everyone working on it, we should
knock the documentation out in no time. ;^)

lata
-j
<jf...@us...>

[Dynapi-Dev] Mods re-modded

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

Okay, gang.  I was able to fix a few bugs in my patches and get all the
broken widgets (on the list provided by Rob) working again...with the
exception of core.gui.scrollbar, which is giving me a strange error that
doesn't appear in the other scrollbar-type widgets (??)

So please take a moment and kindly re-test :-)

Some of the problems were actually conflicting ID problems involving
DynLayer.  When you do this:

function MyWidget(title){

}
...
MyWidget.prototype=new DynLayer()

Remember that the first parameter passed in your constructor will also
be used as the ID of the widget, unless you tell it otherwise, like
this:

function MyWidget(title){
  this.id = "MyWidget" + (MyWidget.Count++)

}
...
MyWidget.Count = 0
MyWidget.prototype=new DynLayer()

This ensures that each widget gets a unique ID.  Without it, two
MyWidget object with the same 'title' will end up having the same ID,
and the second one will overwrite the first in the all[] array when
assigned.

In my patches I've put a line in createElement that pops up an alert
when two DynLayer-based objects have conflicting IDs in the same all[]
collection.

[Dynapi-Dev] IbsWindow bug fix

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

In bug-testing my core mods, I found a small but potentially damaging
bug in IbsWindow.  I've posted the patch with notation at SourceForge.

scottandrew

Re: [Dynapi-Dev] Minor issues with new release

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

Hey Darin, welcome back!

The context menu has been disabled so right-click events could be
captured by DynAPI for custom handlers.  But I see no reason why we
couldn't have a boolean switch somewhere.

In the meantime, remove this line from the bottom of captureEvents in
events.js

if (type=="rtmousedown" || type=="rtmouseup") return false

If my mods are approved, the changes I made to events.js will trap the
mouse button and expose it on the MouseEvent, eliminating the need for
"rtmousedown" handlers.  You can just test for the button type in your
regular mousedown and branch from there.


Darin Kadrioski wrote:
> 
> On a side note, I think I like this mailing-list *far* better then the
> forums  :)
> 
> Trying out the LITE packages.  Excellent idea, however you would never be
> able to use the dyndocument lite in it's current incarnation and be able to
> handle a resize situation.  Without the getX, getW, etc.. an error will
> occur.
> 
> Has anyone else noticed that IE's normal right-click capabilities are now
> disabled?  This can be a nice feature for some pages, but how does one turn
> it back on?
> 
> I know I haven't been very involved in the DynAPI lately, but rest assured
> I've been busy.  I should be finishing up my component pack shortly!  :)
> 
> Cheers.
> 
> --------------------------------------------------
> Darin Kadrioski
> Applications/Internet Developer
> 
> > Electronic Freight Exchange, Corp.
> dka...@ef...
> (916) 933-0724 x315
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] Minor issues with new release

[Darin K. <dka...@ef...>]

On a side note, I think I like this mailing-list *far* better then the
forums  :)

Trying out the LITE packages.  Excellent idea, however you would never be
able to use the dyndocument lite in it's current incarnation and be able to
handle a resize situation.  Without the getX, getW, etc.. an error will
occur.

Has anyone else noticed that IE's normal right-click capabilities are now
disabled?  This can be a nice feature for some pages, but how does one turn
it back on?

I know I haven't been very involved in the DynAPI lately, but rest assured
I've been busy.  I should be finishing up my component pack shortly!  :)

Cheers.

--------------------------------------------------
Darin Kadrioski
Applications/Internet Developer

> Electronic Freight Exchange, Corp.
dka...@ef...
(916) 933-0724 x315

Re: [Dynapi-Dev] Scott: resizeHandler()

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

The resizeHandler method was originally assigned to the onresize handler
only for the *base dyndocument* , which is DynAPI.document.  I've
rearranged it so it will handle multiple dyndocs.

The problem with this is that if you have more than one window with a
dyndocument, the resizeHandler doesn't take care of both of them.  For
example, if you had a main window and a pop-up window, both with
dyndocuments, resizeHandler is only called when you resize the main
window.  Resizing the pop-up does nothing, because resizeHandler (as it
is written now) only affects DynAPI.document.

So I rewrote DynDocument to automatically assign resizeHandler to the
onresize of the frame passed as an argument, which guarantees it will be
executed for *any* dyndocument.  If you look in dyndocument.js, in the
constructor you'll see these lines:

frame.onresize = DynAPI.resizeHandler // <-- [5] handle resize within
scope of this frame, not just top-level
...
frame.dyndoc=this //<-- [7] this is much better

So now if we have multiple dyndocuments in multiple frames or windows,
the resizeHandler executes within the scope of the calling window.  The
way it was before, resizeHandler was only being called when the
top-level parent window was resized.

So then I had to rewrite the resizeHandler to use "this.dyndoc" ("this"
being the frame object that invoke onresize) instead of defaulting to
DynAPI.document.

Does that make sense?

Re: [Dynapi-Dev] DOM support/documentation

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

> I've got all my code working under Mozilla, so I'd say that it
> does support NS6

You're right.  I just tested a few widgets under Mozilla M18 and NS6. 
They seem to work okay, so there must be *some* backwards-compatibility
with regards to event handling and element positioning. Dragging is kind
of jerky, like IE.

Regardless, I don't think the API as it is written now is taking full
advantage of the DOM in those browsers. Maybe later I'll go in and
experiment, but it's not a priority right now I guess.

RE: [Dynapi-Dev] identification od versions

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

sort of like the version property of the DynAPI object ?
(but remembering to increase it before the release is difficult ;)

One serious thing about patches is this: they should be considered
as "dynapi-developer" material not end user code.. Patches are usually
only tested on a single system (1 maybe 2 browsers) and therefor might
not be stable to include in the real code.

I do agree that comments should be more clear for the patch, and I think
this mailing list can be helpfull for that because patches can be mailed
containing a better explanation (thank god for interpreted code).

if the code was documentated by the authors, the documentation wouldn't be
the
problem here ;-)   I think that the documentation project is a good idea and
that new code (basically patches/bug-fixes) should be explained (possibly
using
the mailing list again) so that the "people doing the documentation" can
update
the docs..

the private and public problem could be solved with a good developers
reference
stating what's private and what's not.. other documentation should simply
talk about
public functions/properties only and leave the "inner-workings" of the
DynAPI out of
the picture, just a thought.

I've been looking at Dan's original developers reference (making some
changes
and updates) but it's far from uptodate.. so if anybody wants it just say
it, and
I'll mail it to you (developers reference, NOT end-user documentation)



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



-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens SReindl
Verzonden: vrijdag 27 oktober 2000 13:02
Aan: dynapi dev
Onderwerp: [Dynapi-Dev] identification od versions


Hi DynApicators,

as I follow the discussion in here and in the help list, I believe, one of
the problems is the identification of the versions.

So, why not inserting a line, which shows at least the date and time of
creation or, if there is some kind of central control (who?), a running
version number? This should help to avoid confusion.

Also, I would appreciate if (patch) authors could mark the lines they
changed, may be together with a short explanation of why they did it. If you
have problems with the file size, you can remove the comments by your own.

Thirdly, concerning the "documentation project": I would appreciate very
much, if the code could be documented by the author at least in so far as
that I would like to know the purpose and scope (see below) of the function.
It's not that I cannot understand, what she/he was doing, but it costs some
extra time to analyze the code.

Lastly, I think, many functions are merely ment for INTERNAL use inside of
the DynAPI. In the language of OOP, they would be marked protected or even
private. They are not part of the API. Could we get some agreement of how
name those functions and to distinguish them from "outer" (exported, public,
...) API functions? For users, it should be not neccessary to understand all
this internal stuff to use the API.

Greetings,

Dr. Stephan Reindl
 
Mail: SR...@la... <mailto:SR...@la...>
Internet: www.lamello.de <http://www.lamello.de>


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

RE: [Dynapi-Dev] DOM support/documentation

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

I've got all my code working under Mozilla, so I'd say that it
does support NS6

some of the code checks for is.ns5  and not for is.dom

there are still some minor issues with DynAPI-Mozilla, but this
might be because of rendering bugs in Mozilla.. so hard to track down
the bugs.



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


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Scott Andrew
LePera
Verzonden: donderdag 26 oktober 2000 21:32
Aan: dynapi
Onderwerp: [Dynapi-Dev] DOM support/documentation


I apologize for being such a chatterbox today :-)

Someone mentioned that DynAPI2 supports NS6.  But I'm looking through
the distro and only see scattered DOM support.  For example, the code to
create layers in NS6 is there, but the code to move them (moveTo) is
not.  This is the case for a lot of basic methods.

I'm going to do some testing today (it's a slow day) and see what I can
do to help resolve this.  Until then, should we mention NS6/DOM support?

RE Documentation: I am willing to at least start, but maybe the
distribution should be cleaned up first (widgets separated, patches
evalutated and added, etc.)?
_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

[Dynapi-Dev] identification od versions

[SReindl <SR...@la...>]

Hi DynApicators,

as I follow the discussion in here and in the help list, I believe, one of
the problems is the identification of the versions.

So, why not inserting a line, which shows at least the date and time of
creation or, if there is some kind of central control (who?), a running
version number? This should help to avoid confusion.

Also, I would appreciate if (patch) authors could mark the lines they
changed, may be together with a short explanation of why they did it. If you
have problems with the file size, you can remove the comments by your own.

Thirdly, concerning the "documentation project": I would appreciate very
much, if the code could be documented by the author at least in so far as
that I would like to know the purpose and scope (see below) of the function.
It's not that I cannot understand, what she/he was doing, but it costs some
extra time to analyze the code.

Lastly, I think, many functions are merely ment for INTERNAL use inside of
the DynAPI. In the language of OOP, they would be marked protected or even
private. They are not part of the API. Could we get some agreement of how
name those functions and to distinguish them from "outer" (exported, public,
...) API functions? For users, it should be not neccessary to understand all
this internal stuff to use the API.

Greetings,

Dr. Stephan Reindl
 
Mail: SR...@la... <mailto:SR...@la...>
Internet: www.lamello.de <http://www.lamello.de>

[Dynapi-Dev] IBS widgets

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

Okay, I downloaded the FULL distribution of DynAPI2, dropped in my
modifications and tested all of the IBS widgets, as-is in the distro.

AND I found a bug in my mod of dynapi.js that threw a serious error, in
removeFromArray.

Once I fixed it, IBS stuff worked fine.  I'm sending the patch in now
for removeFromArray.  Please re-test.

scottandrew

Re[2]: [Dynapi-Dev] Scott's Update

[Robert R. <rai...@us...>]

> The current DynAPI Core distribution is missing DynAPI.getImage() !

The getImage is in core.ext.images.js.  So it has to be included to
work.  Another suggestion, is the widgets should have a comment line, listing
the requirements (such as core.ext.images.js is required, etc).



Later,
Robert <rai...@us...>