FAQFAQ   SearchSearch   UsergroupsUsergroups   RegisterRegister   ProfileProfile    Log inLog in   RSS Feed

Dummy Message
Goto page Previous  1, 2, 3 ... 14, 15, 16 ... 21, 22, 23  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Salling Software Forums Forum Index -> Archives
View previous topic :: View next topic  
Author Message
marook
Hero


Joined: 30 Jul 2004
Posts: 336
Location: Copenhagen

PostPosted: Sun Jul 06, 2003 1:33 pm    Post subject: Re: OT File Transfer App OSX Reply with quote

Hi.

I seem to remember my brother talking about this (he has a P800) and=20
the P800 should not have this service. You option is the other way=20
around, send the item from the phone to the Mac.

Hope it helps... :-/

On s=F8ndag, jul 6, 2003, at 12:40 Europe/Copenhagen, Larry Elliott wrote:

> When I do I get an error message "Device does not have the necessary=A0
> services"
>
> On Sunday, July 6, 2003, at 10:11=A0 PM, Ola L=F6fgren wrote:
>
> > Can't you just use the Browse device in the bluetooth menu?
> >
> > /Ola
> >
> >
> >
> > On Sunday, Jul 6, 2003, at 11:04 Europe/Stockholm, Larry Elliott=20
> wrote:
> >
> >> I am looking for a file transfer app for OSX that will enable me to=A0
> >> see
> >> the files on my P800 from my Powerbook and then transfer them to my
> >> Powerbook.
> >>
> >> Any suggestions?
>

____________________________________________
Jakob Peterh=E4nsel
Technical Engineer
Tel: +45 7022 1014
Fax: +45 7022 1013
Mob: +45=A040 16 38 06
jp@n...
www.NetPoint.com

Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
Guest






PostPosted: Thu Jul 10, 2003 10:33 am    Post subject: Re: "Hello, user" speech script Reply with quote

> Date: Thu, 10 Jul 2003 09:44:22 +0200
> From: Marook Zuug Kenja
>
> On onsdag, jul 9, 2003, at 14:34 Europe/Copenhagen, Ashley Ward wrote:
>> Can you send me a copy of your package-for Perl script, Jakob?  I'd
>> like to know which package 'niutil' is a part of.
>
> Sure.
> Remember to set it executable and place it somewhere handy:
>
> Usage in Terminal:
> user% ./package-for

Thanks Jackob.

Unfortunately it seems to give a blank answer for niutil.

[ip-226-97-dhcp:~] ashley% ./bin/package-for whoami
whoami (/usr/bin/whoami): Essentials
[ip-226-97-dhcp:~] ashley% ./bin/package-for defaults
defaults (/usr/bin/defaults): BSD
[ip-226-97-dhcp:~] ashley% ./bin/package-for ls
ls (/bin/ls): BaseSystem
[ip-226-97-dhcp:~] ashley% ./bin/package-for niutil
niutil (/usr/bin/niutil):
[ip-226-97-dhcp:~] ashley%

So in the absence of evidence to the contrary, I guess niutil is
installed as standard, and so safe to use in a portable Clicker action.
?

Ashley.

--
Ashley Ward: Teaching Fellow. Academic, PhD student, Musician
Department of Computer Science, University of Warwick, Coventry
Room 3.21 | Tel: +44 (0)24 765 73774 | Fax: +44 (0)24 7657 3024
ashley@d... http://www.dcs.warwick.ac.uk/~ashley/

Back to top
Guest






PostPosted: Tue Jul 22, 2003 1:28 pm    Post subject: Re: Aborting Proximity Leave Reply with quote

> Date: Mon, 21 Jul 2003 19:26:38 +0200
> From: Jonas Salling
> Subject: Re: Re: Aborting Proximity Leave
>
> My 2 (or 3) cents:
>
> 1. I think returning false from a proximity script would work fine. I
> kind of like this better than calling a command in Clicker, as what's
> going on is a change in the flow of what events are called (this time
> around), as opposed to a permanent change to an object inside Clicker.

Yup, agreed. So returning 'false' from a proximity script should abort
execution of all the following proximity actions. Then the user can
just put the abort script at the top of the list to be executed first.

Will this be in 2.0?

> 2. Allowing script access to the proximity actions won't be in 2.0, I'm
> afraid.

Will it be possible to test the proximity actions without turning the
phone off? (Sorry to pester :>).

> 3. Showing an AppleScript dialog from proximity scripts currently
> doesn't work because the scripts are run in a non-UI thread. This has
> been fixed in 2.0.

Great!

Ashley.

--
Ashley Ward: Teaching Fellow. Academic, PhD student, Musician
Department of Computer Science, University of Warwick, Coventry
Room 3.21 | Tel: +44 (0)24 765 73774 | Fax: +44 (0)24 7657 3024
ashley@d... http://www.dcs.warwick.ac.uk/~ashley/


Back to top
salling
Site Admin


Joined: 27 Jul 2004
Posts: 7498
Location: Stockholm, Sweden

PostPosted: Tue Jul 22, 2003 3:13 pm    Post subject: Re: Re: Aborting Proximity Leave Reply with quote

Thinking about this a little bit more, does this mechanism actually
make sense (except for in a puristic scripting sense)? It may be much
easier for the user to check a checkbox called "Confirm Away Event" in
the "Proximity" tab than to find and place a specific script in front
of all other scripts.

Is there any reason one would want a more flexible behavior than what's
been discussed? Would one ever want to replace the confirmation script?
Does it make sense to have half of the "away actions" run? If not, the
checkbox solution seems fine with me; the other stuff is nice from a CS
standpoint, but not necessarily the easiest to use solution.

Let me know what you think.

Cheers,
Jonas


On tisdag, jul 22, 2003, at 13:28 Europe/Stockholm, Ashley Ward wrote:

>> Date: Mon, 21 Jul 2003 19:26:38 +0200
>> From: Jonas Salling
>> Subject: Re: Re: Aborting Proximity Leave
>>
>> My 2 (or 3) cents:
>>
>> 1. I think returning false from a proximity script would work fine. I
>> kind of like this better than calling a command in Clicker, as what's
>> going on is a change in the flow of what events are called (this time
>> around), as opposed to a permanent change to an object inside Clicker.
>
> Yup, agreed. So returning 'false' from a proximity script should abort
> execution of all the following proximity actions. Then the user can
> just put the abort script at the top of the list to be executed first.
>
> Will this be in 2.0?
>
>> 2. Allowing script access to the proximity actions won't be in 2.0,
>> I'm
>> afraid.
>
> Will it be possible to test the proximity actions without turning the
> phone off? (Sorry to pester :>).
>
>> 3. Showing an AppleScript dialog from proximity scripts currently
>> doesn't work because the scripts are run in a non-UI thread. This has
>> been fixed in 2.0.
>
> Great!
>
> Ashley.
>
> --
> Ashley Ward: Teaching Fellow. Academic, PhD student, Musician
> Department of Computer Science, University of Warwick, Coventry
> Room 3.21 | Tel: +44 (0)24 765 73774 | Fax: +44 (0)24 7657 3024
> ashley@d... http://www.dcs.warwick.ac.uk/~ashley/
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Free shipping on all inkjet cartridge & refill kit orders to US &
> Canada. Low prices up to 80% off. We have your brand: HP, Epson,
> Lexmark & more.
> http://www.c1tracking.com/l.asp?cid=5510
> http://us.click.yahoo.com/GHXcIA/n.WGAA/ySSFAA/EGnolB/TM
> ---------------------------------------------------------------------
> ~->
>
> To unsubscribe from this group, send an email to:
> ericssonclient-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


Back to top
View user's profile Send private message Send e-mail Visit poster's website
marook
Hero


Joined: 30 Jul 2004
Posts: 336
Location: Copenhagen

PostPosted: Tue Jul 22, 2003 3:38 pm    Post subject: Re: Re: Aborting Proximity Leave Reply with quote

Hi All.

I vote for the native "Confirm Away Event" checkbox.
If added natively, it might would be cool to have it in the Menu also,=20
next to the Presentation Mode option.

My 2 cent...

On tirsdag 22. juli 2003, at 15:11, Jonas Salling wrote:

> Thinking about this a little bit more, does this mechanism actually=A0
> make sense (except for in a puristic scripting sense)? It may be much=A0
> easier for the user to check a checkbox called "Confirm Away Event" in=A0
> the "Proximity" tab than to find and place a specific script in front=A0
> of all other scripts.
>
> Is there any reason one would want a more flexible behavior than=20
> what's=A0
> been discussed? Would one ever want to replace the confirmation=20
> script?=A0
> Does it make sense to have half of the "away actions" run? If not, the=A0
> checkbox solution seems fine with me; the other stuff is nice from a=20
> CS=A0
> standpoint, but not necessarily the easiest to use solution.
>
> Let me know what you think.
>
>

____________________________________________
Jakob Peterh=E4nsel
Technical Engineer
Tel: +45 7022 1014
Fax: +45 7022 1013
Mob: +45=A040 16 38 06
jp@n...
www.NetPoint.com

Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
Guest






PostPosted: Tue Jul 22, 2003 3:51 pm    Post subject: Re: Re: Aborting Proximity Leave Reply with quote

i'd vote for a scripting interface for this because this way we can do neat
things like defiining programmatically how the leave event gets aborted
(time limits, applications that may be running, user input, time of day,
etc.).

mgm
----- Original Message -----
From: "Marook Zuug Kenja"
To:
Sent: Tuesday, July 22, 2003 9:38 AM
Subject: Re: Re: Aborting Proximity Leave


Hi All.

I vote for the native "Confirm Away Event" checkbox.
If added natively, it might would be cool to have it in the Menu also,
next to the Presentation Mode option.

My 2 cent...

On tirsdag 22. juli 2003, at 15:11, Jonas Salling wrote:

> Thinking about this a little bit more, does this mechanism actually
> make sense (except for in a puristic scripting sense)? It may be much
> easier for the user to check a checkbox called "Confirm Away Event" in
> the "Proximity" tab than to find and place a specific script in front
> of all other scripts.
>
> Is there any reason one would want a more flexible behavior than
> what's
> been discussed? Would one ever want to replace the confirmation
> script?
> Does it make sense to have half of the "away actions" run? If not, the
> checkbox solution seems fine with me; the other stuff is nice from a
> CS
> standpoint, but not necessarily the easiest to use solution.
>
> Let me know what you think.
>
>

____________________________________________
Jakob Peterhänsel
Technical Engineer
Tel: +45 7022 1014
Fax: +45 7022 1013
Mob: +45 40 16 38 06
jp@n...
www.NetPoint.com




----------------------------------------------------------------------------
----




The information contained in this message is confidential or protected
by law.
If you are not the intended recipient, please contact the sender and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is
prohibited.



Back to top
salling
Site Admin


Joined: 27 Jul 2004
Posts: 7498
Location: Stockholm, Sweden

PostPosted: Tue Jul 22, 2003 3:56 pm    Post subject: Re: Re: Aborting Proximity Leave Reply with quote

Well. There's nothing that prevents use from having both, with the
nerds out there doing things the way they like?

- jonas

On Tuesday, July 22, 2003, at 03:51 PM, Micah Gideon Modell wrote:

> i'd vote for a scripting interface for this because this way we can do
> neat
> things like defiining programmatically how the leave event gets aborted
> (time limits, applications that may be running, user input, time of
> day,
> etc.).
>
> mgm
> ----- Original Message -----
> From: "Marook Zuug Kenja"
> To:
> Sent: Tuesday, July 22, 2003 9:38 AM
> Subject: Re: Re: Aborting Proximity Leave
>
>
> Hi All.
>
> I vote for the native "Confirm Away Event" checkbox.
> If added natively, it might would be cool to have it in the Menu also,
> next to the Presentation Mode option.
>
> My 2 cent...
>
> On tirsdag 22. juli 2003, at 15:11, Jonas Salling wrote:
>
>> Thinking about this a little bit more, does this mechanism actually
>> make sense (except for in a puristic scripting sense)? It may be much
>> easier for the user to check a checkbox called "Confirm Away Event" in
>> the "Proximity" tab than to find and place a specific script in front
>> of all other scripts.
>>
>> Is there any reason one would want a more flexible behavior than
>> what's
>> been discussed? Would one ever want to replace the confirmation
>> script?
>> Does it make sense to have half of the "away actions" run? If not, the
>> checkbox solution seems fine with me; the other stuff is nice from a
>> CS
>> standpoint, but not necessarily the easiest to use solution.
>>
>> Let me know what you think.
>>
>>
>
> ____________________________________________
> Jakob Peterhänsel
> Technical Engineer
> Tel: +45 7022 1014
> Fax: +45 7022 1013
> Mob: +45 40 16 38 06
> jp@n...
> www.NetPoint.com
>
>
>
>
> -----------------------------------------------------------------------
> -----
> ----
>
>
>
>
> The information contained in this message is confidential or protected
> by law.
> If you are not the intended recipient, please contact the sender and
> delete this message. Any unauthorised copying of this message or
> unauthorised distribution of the information contained herein is
> prohibited.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
> Free shipping on orders $50 or more to the US and Canada.
> http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
> http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/EGnolB/TM
> ---------------------------------------------------------------------
> ~->
>
> To unsubscribe from this group, send an email to:
> ericssonclient-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>


Back to top
View user's profile Send private message Send e-mail Visit poster's website
Guest






PostPosted: Tue Jul 22, 2003 4:06 pm    Post subject: Re: Re: Aborting Proximity Leave Reply with quote

hehe! and, of course, i'm a backseat driver - i propose these things
without having done anything more than tweak others' scripts. having both
programmatic and preference driven script abortion capabilities would be
great!

mgm
----- Original Message -----
From: "Jonas Salling"
To:
Sent: Tuesday, July 22, 2003 9:55 AM
Subject: Re: Re: Aborting Proximity Leave


Well. There's nothing that prevents use from having both, with the
nerds out there doing things the way they like?

- jonas

On Tuesday, July 22, 2003, at 03:51 PM, Micah Gideon Modell wrote:

> i'd vote for a scripting interface for this because this way we can do
> neat
> things like defiining programmatically how the leave event gets aborted
> (time limits, applications that may be running, user input, time of
> day,
> etc.).
>
> mgm
> ----- Original Message -----
> From: "Marook Zuug Kenja"
> To:
> Sent: Tuesday, July 22, 2003 9:38 AM
> Subject: Re: Re: Aborting Proximity Leave
>
>
> Hi All.
>
> I vote for the native "Confirm Away Event" checkbox.
> If added natively, it might would be cool to have it in the Menu also,
> next to the Presentation Mode option.
>
> My 2 cent...
>
> On tirsdag 22. juli 2003, at 15:11, Jonas Salling wrote:
>
>> Thinking about this a little bit more, does this mechanism actually
>> make sense (except for in a puristic scripting sense)? It may be much
>> easier for the user to check a checkbox called "Confirm Away Event" in
>> the "Proximity" tab than to find and place a specific script in front
>> of all other scripts.
>>
>> Is there any reason one would want a more flexible behavior than
>> what's
>> been discussed? Would one ever want to replace the confirmation
>> script?
>> Does it make sense to have half of the "away actions" run? If not, the
>> checkbox solution seems fine with me; the other stuff is nice from a
>> CS
>> standpoint, but not necessarily the easiest to use solution.
>>
>> Let me know what you think.
>>
>>
>
> ____________________________________________
> Jakob Peterhänsel
> Technical Engineer
> Tel: +45 7022 1014
> Fax: +45 7022 1013
> Mob: +45 40 16 38 06
> jp@n...
> www.NetPoint.com
>
>
>
>
> -----------------------------------------------------------------------
> -----
> ----
>
>
>
>
> The information contained in this message is confidential or protected
> by law.
> If you are not the intended recipient, please contact the sender and
> delete this message. Any unauthorised copying of this message or
> unauthorised distribution of the information contained herein is
> prohibited.
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges & Refill Kits for Your Epson at Myinks.com
> Free shipping on orders $50 or more to the US and Canada.
> http://www.c1tracking.com/l.asp?cid=5705&lp=home/epson.asp
> http://us.click.yahoo.com/brYXfA/_xWGAA/ySSFAA/EGnolB/TM
> ---------------------------------------------------------------------
> ~->
>
> To unsubscribe from this group, send an email to:
> ericssonclient-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/
>
>



To unsubscribe from this group, send an email to:
ericssonclient-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



Back to top
Guest






PostPosted: Tue Jul 22, 2003 4:33 pm    Post subject: Re: Aborting Proximity Leave Reply with quote

I know I would like to be able to use the scripting interface to be able to toggle this
proximity value on or off via a phone script, so if I knew I was going to have to go
out, but would be back briefly, the proximity sensor wouldn't activate a script I run to
turn off a timestamp program that is running / and of course the iTunes may be
required to keep playing ;)

I'm not sure if I'm missing a point here, if implemented into the syntax, would we be
required to place a script as the first proximity event with the proximity value set to
false. Or could we set this value from a script running in the phone, which in effect
would be the same as having a checkbox, but would open the flexibility of using the
feature in a dynamic way - leaving only the imaginations of scripters to invent new
ways of using the feature.

my two pennies worth .. :)

ket

--- In ericssonclient@yahoogroups.com, Jonas Salling wrote:
> Thinking about this a little bit more, does this mechanism actually
> make sense (except for in a puristic scripting sense)? It may be much
> easier for the user to check a checkbox called "Confirm Away Event" in
> the "Proximity" tab than to find and place a specific script in front
> of all other scripts.
>
> Is there any reason one would want a more flexible behavior than what's
> been discussed? Would one ever want to replace the confirmation script?
> Does it make sense to have half of the "away actions" run? If not, the
> checkbox solution seems fine with me; the other stuff is nice from a CS
> standpoint, but not necessarily the easiest to use solution.
>
> Let me know what you think.
>
> Cheers,
> Jonas
>
>


Back to top
Guest






PostPosted: Thu Jul 24, 2003 2:03 pm    Post subject: Re: Aborting Proximity Leave Reply with quote

>>>> Date: Mon, 21 Jul 2003 14:03:43 +0100
>>>> From: Ashley Ward
>>>> Subject: Aborting Proximity Leave
>>>>
>>>> display dialog "Abort running Clicker 'Leave' scripts? (Continue
>>>> automatically in 3 seconds)" buttons ["Abort", "Continue"] default
>>>> button 1 giving up after 3 with icon stop
>>>> if button returned of result is "Abort" then
>>>> beep
>>>> return false
>>>> else
>>>> return true
>>>> end if
>>>>
>>>> I'm wondering a) if it's possible to use 'display dialog' in
>>>> proximity
>>>> scripts, b) if it is possible to abort the execution of all
>>>> proximity
>>>> actions by returning a value from a script, say.
>>>
>>> Date: Tue, 22 Jul 2003 15:11:49 +0200
>>> From: Jonas Salling
>>> Subject: Re: Re: Aborting Proximity Leave
>>>
>>> Thinking about this a little bit more, does this mechanism actually
>>> make sense (except for in a puristic scripting sense)? It may be much
>>> easier for the user to check a checkbox called "Confirm Away Event"
>>> in
>>> the "Proximity" tab than to find and place a specific script in front
>>> of all other scripts.
>>>
>>> Is there any reason one would want a more flexible behavior than
>>> what's
>>> been discussed? Would one ever want to replace the confirmation
>>> script?
>>> Does it make sense to have half of the "away actions" run? If not,
>>> the
>>> checkbox solution seems fine with me; the other stuff is nice from a
>>> CS
>>> standpoint, but not necessarily the easiest to use solution.
>>>
>>> Let me know what you think.
>>>
>>> Cheers,
>>> Jonas
>>
>> Date: Tue, 22 Jul 2003 09:51:40 -0400
>> From: "Micah Gideon Modell"
>> Subject: Re: Re: Aborting Proximity Leave
>>
>> i'd vote for a scripting interface for this because this way we can
>> do neat
>> things like defiining programmatically how the leave event gets
>> aborted
>> (time limits, applications that may be running, user input, time of
>> day,
>> etc.).
>>
>> mgm
>
>
> Message: 11
> Date: Tue, 22 Jul 2003 15:55:15 +0200
> From: Jonas Salling
> Subject: Re: Re: Aborting Proximity Leave
>
> Well. There's nothing that prevents use from having both, with the
> nerds out there doing things the way they like?
>
> - jonas

Doing this as a script was a pure CS motivation, you are right :) (well
-- and also helping the Clicker cause but without the source code...).
It would be a neat thing to be able to do... and mgm's examples
illustrate the potential for programmatically aborting a leave event.

I agree it would be much easier for a user to tick "allow leave event
aborting" or something ("confirm away event" is impossible if you
really have gone away :>) rather than having to put a script in the
right place. But different people might want different timeouts on the
abort dialog... so perhaps provide a simple built-in one (BTW, can we
have a "...in 3 seconds... in 2 seconds..." countdown?), but also give
the ability to script something.

Aborting only some of the away actions in response to an abort dialog?
Hum... I don't think I can think of any examples here. This started
because my phone sometimes loses the BT connection and I want to
correct that error if I'm actively using the machine. But it might be
useful programmatically in different circumstances... perhaps something
has gone so drastically wrong in one action (disk full? Internet
connection down? burnt the toast? ;>) that to continue with others
would be pointless, perhaps even harmful?

I can also think of other uses for being able to do 'display dialog'
from a proximity "return" (clarifying the words to use would be useful:
away/leave/left/gone, come back/return/arrive/appear?) script: how
about "would you like to iSync now? [yes/no]", or "do you fancy some
dance, classical or pop music now? [dance/classical/pop/silence
please]" on returning to your Mac?

Ashley (who is off on holiday for a week shortly and looks forward to
reading more when he returns)

--
Ashley Ward: Teaching Fellow. Academic, PhD student, Musician
Department of Computer Science, University of Warwick, Coventry
Room 3.21 | Tel: +44 (0)24 765 73774 | Fax: +44 (0)24 7657 3024
ashley@d... http://www.dcs.warwick.ac.uk/~ashley/


Back to top
salling
Site Admin


Joined: 27 Jul 2004
Posts: 7498
Location: Stockholm, Sweden

PostPosted: Mon Aug 11, 2003 3:44 pm    Post subject: Re: losing connection between t610 and clicker on Powerbook Reply with quote

Hello!

What are the circumstances? If the Bluetooth icon (I assume you mean
Apple's "Bluetooth icon", right?) is acting up, you may be experiencing
some sort of problem in OS X's Bluetooth software. However, I think we
need more info to figure out a remedy.

Best,
Jonas

On måndag, aug 11, 2003, at 15:34 Europe/Stockholm, koobrik wrote:

> I tried Clicker and really like the way it works. My only problem is
> that I keep on losing the connection between my t610 and my Powerbook.
> I am using a 12" Powerbook G4. I tried using it with my iMac. It
> also lost the connection but the circumstances were different. When
> losing the connection to the Powerbook, the bluetooth icon would
> revert to the regular bluetooth icon which shows its on but not
> connected. When losing the connection to the iMac, the bluetooth icon
> on my t610 would still show that it is connected, even if it has lost
> the connection. Anyone experience this?


Back to top
View user's profile Send private message Send e-mail Visit poster's website
Guest






PostPosted: Wed Aug 13, 2003 12:09 am    Post subject: Re: losing connection between t610 and clicker on Powerbook Reply with quote

This is really embarrassing but I realized soon after posting my first
message that Clicker worked for only 30 clicks in demo mode. I even
deleted that post, but apparently, it was not deleted. I don't know
why I missed that, but I only realized that when I checked out your
site. I have registered my copy of Clicker already and have been
enjoying it, especially in my last two Keynote presentations.

About Bluetooth on my iMac, I have a sneaking suspicion it might be my
Mitsumi dongle that's causing an erratic connection. I don't have
much problems with Bluetooth on my 12' Powerbook where bluetooth is
built-in. On my iMac, it is quite erratic. I will probably replace
the dongle with a D-Link.

--- In ericssonclient@yahoogroups.com, Jonas Salling
wrote:
> Hello!
>
> What are the circumstances? If the Bluetooth icon (I assume you mean
> Apple's "Bluetooth icon", right?) is acting up, you may be experiencing
> some sort of problem in OS X's Bluetooth software. However, I think we
> need more info to figure out a remedy.
>
> Best,
> Jonas
>
> On måndag, aug 11, 2003, at 15:34 Europe/Stockholm, koobrik wrote:
>
> > I tried Clicker and really like the way it works. My only problem is
> > that I keep on losing the connection between my t610 and my Powerbook.
> > I am using a 12" Powerbook G4. I tried using it with my iMac. It
> > also lost the connection but the circumstances were different. When
> > losing the connection to the Powerbook, the bluetooth icon would
> > revert to the regular bluetooth icon which shows its on but not
> > connected. When losing the connection to the iMac, the bluetooth icon
> > on my t610 would still show that it is connected, even if it has lost
> > the connection. Anyone experience this?


Back to top
Guest






PostPosted: Wed Sep 03, 2003 8:48 pm    Post subject: Clicker 2.0 and m130 Palm? Reply with quote

Hi...

Clicker 2.0 looks very interesting.

I have an "old" Palm m130 with a Bluetooth SD card. This Palm has Palm
OS 4.1 and has the older Dragonball processor, not ARM. I'm trying
Palm-Clicker despite the warnings on the web that it only works with a
Palm OS 5 device.

I can run the app on the Palm, and can successfully select my iBook
(she's named Izellah), but when I click Connect, I get "Trying to
connect to Izellah", then "Error: Is Clicker on Izellah busy (or not
launched)?".

The Clicker System Preferences pane is launched, sitting there at
"Publish Menu".

Is there any chance of this working?

Ashley.


Back to top
salling
Site Admin


Joined: 27 Jul 2004
Posts: 7498
Location: Stockholm, Sweden

PostPosted: Wed Sep 03, 2003 9:05 pm    Post subject: Re: Clicker 2.0 and m130 Palm? Reply with quote

Do you see anything in your Mac's Console?

Best,
jonas

On onsdag, sep 3, 2003, at 20:40 Europe/Stockholm, Ashley Ward wrote:

>
> I have an "old" Palm m130 with a Bluetooth SD card. This Palm has Palm
> OS 4.1 and has the older Dragonball processor, not ARM. I'm trying
> Palm-Clicker despite the warnings on the web that it only works with a
> Palm OS 5 device.
>
> I can run the app on the Palm, and can successfully select my iBook
> (she's named Izellah), but when I click Connect, I get "Trying to
> connect to Izellah", then "Error: Is Clicker on Izellah busy (or not
> launched)?".
>
> The Clicker System Preferences pane is launched, sitting there at
> "Publish Menu".
>
> Is there any chance of this working?


Back to top
View user's profile Send private message Send e-mail Visit poster's website
Guest






PostPosted: Thu Sep 04, 2003 12:17 pm    Post subject: Re: Clicker 2.0 and m130 Palm? Reply with quote

> On onsdag, sep 3, 2003, at 20:40 Europe/Stockholm, Ashley Ward wrote:
>> I have an "old" Palm m130 with a Bluetooth SD card. This Palm has
>> Palm
>> OS 4.1 and has the older Dragonball processor, not ARM. I'm trying
>> Palm-Clicker despite the warnings on the web that it only works with a
>> Palm OS 5 device.
>>
>> I can run the app on the Palm, and can successfully select my iBook
>> (she's named Izellah), but when I click Connect, I get "Trying to
>> connect to Izellah", then "Error: Is Clicker on Izellah busy (or not
>> launched)?".
>>
>> The Clicker System Preferences pane is launched, sitting there at
>> "Publish Menu".
>>
>> Is there any chance of this working?
>
> Message: 12
> Date: Wed, 3 Sep 2003 20:55:09 +0200
> From: jonassalling@m...
> Subject: Re: Clicker 2.0 and m130 Palm?
>
> Do you see anything in your Mac's Console?
>
> Best,
> jonas

Hi Jonas...

No, nothing at all.

When I use my t68i do I get the following:

2003-09-04 10:52:33.739 SEC Helper[554] Terminal Manufacturer:
'ERICSSON '
2003-09-04 10:52:34.260 SEC Helper[554] Terminal Model: '1130202-BVT68'
2003-09-04 10:52:35.984 SEC Helper[554] Negotiated NSUTF8StringEncoding
for this device

... but when I use the Palm, nothing.

Ashley.


Back to top
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    Salling Software Forums Forum Index -> Archives All times are GMT + 2 Hours
Goto page Previous  1, 2, 3 ... 14, 15, 16 ... 21, 22, 23  Next
Page 15 of 23

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group