try this CSS:
body #calendar_control {
position: fixed !important;
}
it worked for me.
Ted
On Tue, 7/30/13, Lon Varscsak wrote:
Subject: Re: AjaxModalDialog and AjaxDatePicker
To: "Chuck Hill"
Cc: "webobjects-dev@lists.apple.com"
Date: Tue
Hi Joee,
Can you test this out with our usage and let us know if this change works there
too?
Thanks
Chuck
On 2013-07-30, at 5:21 PM, Lon Varscsak wrote:
> lol, I'm not sure I can tell the users that.
>
> There is this line in the calendar.js:
>
> var result = [document.viewport.getScrol
lol, I'm not sure I can tell the users that.
There is this line in the calendar.js:
var result = [document.viewport.getScrollOffsets().left -
$(el).cumulativeScrollOffset().left,
document.viewport.getScrollOffsets().top -
$(el).cumulativeScrollOffset().top];
Which results in [0,0] because the
We see this too. Don't scroll? :-) My guess would be absolute vs relative
positioning.
Chuck
On 2013-07-30, at 4:54 PM, Lon Varscsak wrote:
> Hey all,
>
> I have an AjaxDatePicker on an AjaxModalDialog and am running into a bit of
> trouble. If the page that is launching the AMD is scroll
Hey all,
I have an AjaxDatePicker on an AjaxModalDialog and am running into a bit of
trouble. If the page that is launching the AMD is scrolled down at all,
the AjaxDatePicker is in the wrong location (up at the top as though the
page hadn't been scrolled).
I can actually scroll (the background)
Did you try this <
http://lists.apple.com/archives/webobjects-dev/2013/Apr/msg00023.html> ?
On 30 Jul 2013 17:58, "Johan Henselmans" wrote:
>
> On 30 jul. 2013, at 17:10, Chuck Hill wrote:
>
> > It is the application you need to do this in, not wotaskd. wotaskd uses
> a script to launch a new J
this is the issue, and yes it is still an issue. Yes, please do a pull
request, in the meantime is there any way I could get what you have?
Ted
On Jul 30, 2013, at 12:48 PM, Fabian Peters wrote:
> Ted,
>
> I'm not entirely sure why you would want this behaviour. Is this still to do
> wit
Ted,
I'm not entirely sure why you would want this behaviour. Is this still to do
with your initial problem?:
> If I add an object and immediately click its delete button, my app throws
> a hissy-fit because the object can not be deleted as it is not saved in
> the first place.
T
should you be doing this with your EO?
a job for didInsert() ?
On Jul 30, 2013, at 12:05 PM, Theodore Petrosky wrote:
> This is not directly a reply to David. I am about to try my hand at
> implementing this in my app.
>
> David asks the sensible question if anyone thinks there is a bette
Op 30 jul. 2013, om 17:10 heeft Chuck Hill het
volgende geschreven:
> It is the application you need to do this in, not wotaskd. wotaskd uses a
> script to launch a new JVM for the app so changes to the JVM for wotaskd do
> not affect the application.
>
> Chuck
>
>
I also noticed this i
This is not directly a reply to David. I am about to try my hand at
implementing this in my app.
David asks the sensible question if anyone thinks there is a better way to do
this. Maybe someone can chime in here.
Basically, in a D2W app with to Many relations, when you add a new relationship
Try the specific JVM:
# JVM == /System/Library/Frameworks/JavaVM.framework/Versions/1.7.25/Commands/
java
> Running the app from the command-line gives java 1.7, but running from
> wotaskd gives the following log in
Suggests that the user it is running under when wotaskd starts it ha
On 30 jul. 2013, at 17:10, Chuck Hill wrote:
> It is the application you need to do this in, not wotaskd. wotaskd uses a
> script to launch a new JVM for the app so changes to the JVM for wotaskd do
> not affect the application.
>
> Chuck
>
Been there, done that:
ostadeserver:MacOS root#
Thanks Fabian,
I'm currently looking at both files, trying to compare them. The thing is that
the Maven configuration file includes a lot more jars in the classpath that our
previous configuration (like JavaWOJSPServlet and stuff like that) so I guess I
will try to exclude a few things I don
14 matches
Mail list logo
