How do I get right drivers for my Meade ETX70?

I've started on a plug-in for CCDSoft that allows it to use ASCOM
focusers (similar to the TelescopeAPI plug-in for TheSky). I've got a
settings dialog that brings up the ASCOM Chooser with DeviceType =
"Focuser". It seems to work OK except for four of the supported
focusers. For those four, when I click on the Properties button, I get
the following results...

AstroOptik Telescopes: no properties displayed, but OK button gets
enabled.
AstroPhysics GTO mount, Focus Simulator: Error dialog displayed "Failed
to load driver: object required"
Meade Telescope and Focuser: "Failed to load driver: Invalid object use:
Only one program can use this focuser"

The others all seem to work fine, their ProgID gets saved in the
registry and recalled the next time I launch CCDSoft. Is there a
subtlety in the ASCOM focuser standard that I'm missing, or is there
something odd about these four focusers? In at least two cases here, the
focuser is part of the mount rather than a stand alone device. This
would seem to be true for the simulator too, because I believe it was
based on the scope simulator. I'm not sure about the AstroOptik. Is
there some different treatment needed when the focuser is part of the
mount?


Best regards,

Tim Long






[Non-text portions of this message have been removed]

> AstroOptik Telescopes: no properties displayed, but OK button
> gets enabled. AstroPhysics GTO mount, Focus Simulator: Error
> dialog displayed "Failed to load driver: object required"
> Meade Telescope and Focuser: "Failed to load driver: Invalid
> object use: Only one program can use this focuser"

This sounds like the infamous registry security bug.  Bob,
will have to chime in with a proper work around.  The
next release of the ASCOM platform will be fixing this.

Bob, I will have a release candidate for the focus simulator
within a few days, if you're getting close to a new release?
(Finalizing a test script presently).

Jon

Tim Long:
> AstroOptik Telescopes: no properties displayed, but OK button gets
> enabled.

The AstroOptik.Focuser driver has an empty SetupDialog() method. So don't
worry, this one is OK. And be prepared for another quirk with this one. In
the new ASCOM chooser, if you attempt to set up a device that is already
connected, the Properties... button will pop an alert "The device is already
connected, just click OK". This is because AstroOptik always returns True to
the Link property, even if it is not connected. With AstroOpik you do all
setup with the Telescope dialog.

> AstroPhysics GTO mount, Focus Simulator: Error dialog displayed "Failed
> to load driver: object required"

These are EXE object servers. Can you create an instance of
"AstroPhysics.Telescope"? In the case of Brewster's Focus Simulator, it's
most likely a DCOM perms problem, and this is likely the AP problem too.

Run DCOMCNFG. Answer Yes to the AppID alerts. Eventually you'll get the
Distributed DCOM COnfiguration Properties. Scroll past all the hex xtuff and
find the ASCOM entries. For each: Click on an entry, then click
Properties... Set the Authentication level to None. Once you know that the
authentication level is None for all listed ASCOM entries, try again.

> Meade Telescope and Focuser: "Failed to load driver: Invalid object use:
> Only one program can use this focuser"

This indicates that something else already has created and not released a
MeadeEx.Focuser. This is a problem when doing development because the
MeadeEx driver is an EXE. If something goes wrong where an orphan instance
of MeadeEx.Focuser (or MeadeEx.Telescope) gets left there, You'll get this
message. Open the Task Manager, go to Processes, find MeadeEx Driver.exe and
kill it. Now re-run your test.

   -- Bob

BREWSTER,JON A (HP-Corvallis,ex1):
> Bob, I will have a release candidate for the focus simulator
> within a few days, if you're getting close to a new release?
> (Finalizing a test script presently).

Great! A couple of nits I noted:

It shows up in object browsers as "ASCOM Telescope driver for telescope
simulator". To fix this open the Object Browser in VB (press F2), scroll to
Focuser (should be bold) and click. Note the description string at the
bottom in the gray area. To change this, right click on Focuser and edit the
Description string. Start it with ASCOM Focuser  (see super-nit below)
                                         ^^^^^^^
You got the Project properties changes for the focus sim because the
helpstring for the type library says "ASCOM focus driver for simulated focuser"

Now this is a REAL nit: The description strings should say ASCOM
[devicetype] ... so: ASCOM Focuser driver for... or ASCOM Telescope driver
                            ^^^^^^^                        ^^^^^^^^^

   -- Bob

OK, thanks for that. Fixed all but the Meade driver.

A process called MEADEE~1.EXE appears _after_ the error is displayed and
hangs around until I kill it.

--Tim




-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday 04 March 2003 07:13
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Focus Chooser


Tim Long:
> AstroOptik Telescopes: no properties displayed, but OK button gets
> enabled.

The AstroOptik.Focuser driver has an empty SetupDialog() method. So
don't worry, this one is OK. And be prepared for another quirk with this
one. In the new ASCOM chooser, if you attempt to set up a device that is
already connected, the Properties... button will pop an alert "The
device is already connected, just click OK". This is because AstroOptik
always returns True to the Link property, even if it is not connected.
With AstroOpik you do all setup with the Telescope dialog.

> AstroPhysics GTO mount, Focus Simulator: Error dialog displayed
> "Failed to load driver: object required"

These are EXE object servers. Can you create an instance of
"AstroPhysics.Telescope"? In the case of Brewster's Focus Simulator,
it's most likely a DCOM perms problem, and this is likely the AP problem
too.

Run DCOMCNFG. Answer Yes to the AppID alerts. Eventually you'll get the
Distributed DCOM COnfiguration Properties. Scroll past all the hex xtuff
and find the ASCOM entries. For each: Click on an entry, then click
Properties... Set the Authentication level to None. Once you know that
the authentication level is None for all listed ASCOM entries, try
again.

> Meade Telescope and Focuser: "Failed to load driver: Invalid object
> use: Only one program can use this focuser"

This indicates that something else already has created and not released
a MeadeEx.Focuser. This is a problem when doing development because the
MeadeEx driver is an EXE. If something goes wrong where an orphan
instance of MeadeEx.Focuser (or MeadeEx.Telescope) gets left there,
You'll get this message. Open the Task Manager, go to Processes, find
MeadeEx Driver.exe and kill it. Now re-run your test.

   -- Bob




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



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

Tim --

Wow, that was fast. Is it possible that your plugin is creating multiple
instances of the Focuser? Probably not, but...

You have the sources for the Meade driver. Do you have VB6 SP5? If so, you
can run the driver in the VB6 IDE. Load the project (MeadeEx Driver.vbp) and
"run" it. Since it is set in Component properties to run as an ActiveX
Component, this will cause th IDE to become the source for objects served.
Put a breakpoint in the Focuser.cls, Class_Initialize() routine. That's
where the test for multiple instances is made. You'll likely see multiple
calls to same. Try to figure out how you're creating more than one instance.

   -- Bob

Hi

Please, does anybody know how is it possible and be able to use the
DigitalSky Voice (V2.02) together with the StarryNight Pro 4 to
control a Celestron Ultima 2K scope?.

Thanks for any suggestions

Regards

Ray

Bob, I'd love to give that a go, BUT:

I'm running VS .NET and the Meade driver will not load in the .NET IDE

I'm not creating any instances of the focuser - I'm just calling the
Chooser with DeviceType = "Focuser", then clicking on Properties.
Actually, not strictly true, I do create a focuser now, but when I wrote
my first post I hadn't even written that code. Does the Meade driver try
to connect to the scope when configuring the focuser settings? I don't
have any scopes attached to my development computer.

Anyway, I've been tinkering all night and I've got square eyes. I'm
going to have to take a break and have another look later.

--Tim




-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday 04 March 2003 07:48
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Focus Chooser


Tim --

Wow, that was fast. Is it possible that your plugin is creating multiple
instances of the Focuser? Probably not, but...

You have the sources for the Meade driver. Do you have VB6 SP5? If so,
you can run the driver in the VB6 IDE. Load the project (MeadeEx
Driver.vbp) and "run" it. Since it is set in Component properties to run
as an ActiveX Component, this will cause th IDE to become the source for
objects served. Put a breakpoint in the Focuser.cls, Class_Initialize()
routine. That's where the test for multiple instances is made. You'll
likely see multiple calls to same. Try to figure out how you're creating
more than one instance.

   -- Bob



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



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

Tim --

If I haven't said so, THANK YOU VERY MUCH for creating the CCDSoft to ASCOM
converter plugin!!! If you want, I'd be happy to include it in the next
ASCOM Platform with full attribution. Open source is preferred, but not
required.

Anyway, as a data point, create a file test.vbs using Notepad, and containing:

Set C = CreateObject("DriverHelper.Chooser")
C.DeviceType = "Focuser"
WScript.Echo C.Choose()

Then double-click it. You'll see the Chooser. Select the Meade Telescope and
Focuser. Click Properties. What happens?

   -- Bob

Hello all --

I'd like to propose the following plan for the near and medium term future
of the ASCOM Platform. COMMENTS ARE SOLICITED!

Telescope Standard V2:                    Approval by Monday March 17
=====================
This appears to be stable. No comments have been received since late
January. See http://ascom-standards.org/Telescope2.html. This will become
the new standard. Platform 2.2 will contain a mixture of V1 and V2 drivers.
There is already at least one V2 driver, the unified NexStar driver (?? am I
right??). Thanks to Chris Rowland and a team of commenters for the V2
standard. WELL DONE! I will update the Telescope Standard helpfile to
include the V2 additions, and will get the new stuff into the Telescope
Simulator. I'll include a V1/V2 selector (however I won't be able to truly
simulate a V1 scope. Once I add the implementations of the new methods and
properties it will return V1 and "not implemented" for the new items,
instead of the low-level COM error you get when trying to call something
that is not even IN the interface).

TELESCOPE DRIVER AUTHORS: If you want to update your driver to V2, please
try to do it before the proposed release date below.

ASCOM Platform 2.2:                      Release Monday March 24
==================
This platform will contain the updates to drivers including the new unified
Telescope for the NexStar. I will add the AppID stuff to all drivers, and
also fix the registry permissions so that the Platform can be used by
non-privileged accounts under 2K/XP. It will contain the Telescope V2
simulator and the V2 Telescope programmer's reference helpfile. Jon
Brewster, if you can complete the ASCOM Focuser Simulator in the next few
weeks, and if it's your desire, I'll include it as well. Actually, I'll wait
to release V2.2 a bit longer if you need just a bit more time. Johathan Fay,
will you have the universal hub in a release state by then. If not, no
worries, we can put it on the ASCOM Download page till the next Platform
release.

DRIVER AUTHORS: Submit your changes, including sources if you want, by
Monday March 17 so I can vet them and make the Platform installer. I have a
STRONG preference for VB6SP5 instead of VB.NET, mainly from a supportability
point of view. I don't want to become a focal point for people having
problems with .NET and the COM Interop stuff. The latter requires the .NET
runtime, and the COM Interop stuff is pretty meaty and there are a lot of
unknowns. I'd prefer not to deal with this stuff till ASCOM Platform V3 (see
below).

Camera and FilterWheel Standards 1.0   Target Approval May 2003
====================================
Possibly we can approve this sooner, but we need to get a reference
implementation and test the interface standard for real-world suitability.
Is 2 months too little time?

ASCOM Platform 3.0                     Target Release June 2003
==================
This would contain all Telescope drivers at V2 of the standard, and possibly
the first set of Camera and FilterWheel drivers. Also, I propose that this
would be the first Platform that would require the .NET runtime, and permit
.NET based drivers. Non .NET would still be preferred for lightness of
weight and known real-world issues. The core components (DriverHelper, etc.)
would still be VB6. It would use the Windows Script 5.6 engines and WSH and
not depend on the .NET scripting stuff. This will preserve interoperability
with Office 2000 and XP, as well as the base of scripts that we currently have.

Once we have commented and adjusted this plan, I'll publish it on the ASCOM
web site.

   -- Bob

Hi --

I want to add two additional propertoes to Telescope V2:

Enum EquatorialSystems
     teleLocalTopocentric = 0           (default)
     teleJ2000 = 1
End Enum

Property EquatorialSystem as EquatorialSystems, read only

Returns teleLocalTopocentric if the telescope needs its instrumental
equatorial coordinates to be in the local topocentric coordinate system.
This is what most of our "amateur" scopes use. However, a couple of new
systems that are using ASCOM (e.g., SciTech, possibly Astrooptik) have the
capability to convert from J2000 to local topocentric built into the
low-level telescope control system. In the case of SciTech, instrumental
inputs -must- be in J2000. This property will return teleJ2000 if the driver
needs J2000 coordinates.

Property HasRefraction as Boolean, read only

Returns True if the low-level telescope control system has refraction
correction built-in. The LX200 does this (and it can't be turned off), and
I'm not sure of others. This would be used to adjust client software to
apply or not apply refraction corrections to pointing.

If there are no objections, I will revise the online draft. Comments???

   -- Bob

Well, don't thank me until I finish it! Finsihing isn't my strong point
;-)

I created your test script and, interestingly, it works. I'll do some
further digging.

--Tim




-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Tuesday 04 March 2003 12:59
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Focus Chooser


Tim --

If I haven't said so, THANK YOU VERY MUCH for creating the CCDSoft to
ASCOM converter plugin!!! If you want, I'd be happy to include it in the
next ASCOM Platform with full attribution. Open source is preferred, but
not required.

Anyway, as a data point, create a file test.vbs using Notepad, and
containing:

Set C = CreateObject("DriverHelper.Chooser")
C.DeviceType = "Focuser"
WScript.Echo C.Choose()

Then double-click it. You'll see the Chooser. Select the Meade Telescope
and Focuser. Click Properties. What happens?

   -- Bob


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



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

Hi,

These extra properties seem fine to me.

Does anyone know if the Celestron scopes allow for refraction?

I will add these into the Celestron driver. It is almost ready and I'll do a
release candidate in the next few days. I will put this in the files area of
the NexStar Group and pass it to Bob for the next release.

This driver supports all the NexStar and the Ultima 2000 scopes except the
Tasco and early GT80 which it recognises and displays a message box saying
that it doesn't work.

Chris
----- Original Message -----
From: "Bob Denny" <rdenny@...>

> I want to add two additional propertoes to Telescope V2:
>
> Enum EquatorialSystems
>     teleLocalTopocentric = 0           (default)
>     teleJ2000 = 1
> End Enum
>
> Property EquatorialSystem as EquatorialSystems, read only
>

Tim --

OK then it is definitely the DCOM permissions problem. Due to the
architecture of CCDSoft and TheSky (no criticism intended here), outbound
ActiveX/COM connections are subject to DCOM perrmission checks. In order to
successfully connect to an EXE-based component server, the server must be
set up to allow DCOM connects. A DLL-based server runs in the context of
CCDSoft/TheSky and therefore does not need interprocess connections and DCOM
is not an issue. That's why the DLL-based drivers work. The Meade issue is a
separate one.

Go ahead and add the DCOM stuff uding DCOMCNFG and see if that doesn't help.

   -- Bob

Chris --

Thanks VERY MUCH for the rapid response. Sure, add the new properties... it
doesn't look like there's going to be a groundswell of dissent :-) By the
way, I used an Enum instead of a BOolean (J2000 vs LocalTopo) to allow for
additional equatorial coordinate systems in the future.

   -- Bob

I have a first-cut ready. Anyone care to take this for a spin? To get a
copy, email me direct (Tim@...) and include the text
[FocusAPIMapper] in the subject line (square brackets included).

Best regards,

Tim Long






[Non-text portions of this message have been removed]

Hi Bob,

> reference helpfile. Jon Brewster, if you can complete the
> ASCOM Focuser Simulator in the next few weeks, and if it's
> your desire, I'll include it as well. Actually, I'll wait to
> release V2.2 a bit longer if you need just a bit more time.

Good schedule.  In a day a two I'll throw a zip watermelon
your way.  The test script is done, and has helped me check out
the edge cases.  I want to walk through the code one more
time.

Jon

Bob,

> Great! A couple of nits I noted:

BTW, I did fix these as per your notes.  Nits are us around here.
Thanks for the pointer into the Object Browser.  I'd been looking
all over for how to clean that one up.

Jon

The list below are my thoughts after ditzing with the Focuser
code for the last couple of weeks:

1) "Link" property could be deprecated (but left in?) "Connected"
    could be added

2) Could use CanHalt, CanStepSize, CanTemperature.  These mentioned
    features throw errors if not implemented currently, which may be
    OK, but...

3) TempCompAvailable could be CanTempComp.  Same as #1
    deprecate, and add the new one

4) Description, DriverInfo, and Name would be nice.  Like
    the scope standard.

None of this is critical.  "Name" is my highest priority.  Its
hard to create a nice GUI if you don't have access to the
friendly name.  I can pull it from the registry, but yick :-)

Jon

At 08:18 04.03.03 -0700, Bob wrote:
>Property EquatorialSystem as EquatorialSystems, read only
>Property HasRefraction as Boolean, read only
>
>Comments???

ACK.  :)

Matthias

BREWSTER,JON A (HP-Corvallis,ex1):
> The list below are my thoughts after ditzing with the Focuser
> code for the last couple of weeks:
>
> 1) "Link" property could be deprecated (but left in?) "Connected"
>    could be added

I have mentioned this one too... inconsistent with the existing Connected
property as used in Telescope, Link is either a noun or a verb, so it could
be the name of a property or a method. Does it mean "link it" or "the link"?
These sorts of things seem nitty I know. But if there's a way to confuse or
misinterpret someone will do so, and it's better to close off that sort of
thing in the design.

> 2) Could use CanHalt, CanStepSize, CanTemperature.  These mentioned
>    features throw errors if not implemented currently [...]

I would agree for the CanHalt. In that case the issue is that you have to
halt the focuser to find out if you can halt it. The other two are
read-write proerties so you can test for implementation via (e.g.)
Focuser.StepSize = Focuser.StepSize without needing a Can flag. Yes you need
to catch errors (Err.Number test is easiest).

> 3) TempCompAvailable could be CanTempComp.  Same as #1
>    deprecate, and add the new one

Yes, again some naming convention between drivers should be strived-for. For
better or for worse, Telescope preceded everything else and is thus a sort
of template for naming.

> 4) Description, DriverInfo, and Name would be nice.  Like
>    the scope standard.

Yes yes.

> None of this is critical.  "Name" is my highest priority.  Its
> hard to create a nice GUI if you don't have access to the
> friendly name.

Yeah, that's what motivated those things in Telescope. They should be there

Any other comments re: a Focuser V2? If we can settle on this quickly
enough, we might be able to get it into the ASCOM Platform V3 in June. Do
any focuser driver authors think this is possible?

   -- Bob

John --

Great! You've definitely had the "ah ha!" experience with all of this!!!

   -- Bob

To anyone who may be able to help,

I am a middle school science teacher who has this type of telescope
(6" Newtonian Reflector Telescope)with these specifications:

Large 150mm (6") concave objective mirror
Objective Mirror: Concave mirror, hard-coated
Lens Clear Aperture: 150mm (6")
Resolving Power: 0.93"
Faintest Discernable Object: 12M
ET-8 Equatorial Mount
Focusing: Smooth Rack and Pinion focusing
Flexible Cable Controls
Balance weight
Focal Length : 1400mm (55")
PL 25mm Eyepiece
PL6.5mm Eyepiece
Moon Filter + Sun Filter
Heavy-duty Lightweight & adjustable Height Aluminum Tripod
Accessory Tray
Manual Included

I am looking for recommendations if possible to purchase a seperate
motor unit that will interface with software. I have not purchased
any software and would like recommendations for that also. I have
looked at Deepsky 2003.

Please help!

Gordon

That would be a good question to ask over in the
ScopeMounts group or the RoboScope group.

http://groups.yahoo.com/group/ScopeMounts

http://groups.yahoo.com/group/RoboScope

I am a moderator in both groups and I am not specifically
familiar with your mount the way you describe it, so
uploading a digital picture of your mount would help a lot
too.

-Christopher Erickson
Network Design Engineer
We Byte
5432 E. Northern Lights Blvd., Suite 529
Anchorage, AK  99508
N61? 11.710'  W149? 46.723'
www.data-plumber.com


> -----Original Message-----
> From: fore_runner_1 [mailto:gglen@...]
> Sent: Wednesday, March 05, 2003 6:47 AM
> To: ASCOM-Talk@yahoogroups.com
> Subject: [ASCOM] 6" Newtonian Reflector Telescope
>
>
> To anyone who may be able to help,
>
> I am a middle school science teacher who has this type of telescope
> (6" Newtonian Reflector Telescope)with these specifications:
>
> Large 150mm (6") concave objective mirror
> Objective Mirror: Concave mirror, hard-coated
> Lens Clear Aperture: 150mm (6")
> Resolving Power: 0.93"
> Faintest Discernable Object: 12M
> ET-8 Equatorial Mount
> Focusing: Smooth Rack and Pinion focusing
> Flexible Cable Controls
> Balance weight
> Focal Length : 1400mm (55")
> PL 25mm Eyepiece
> PL6.5mm Eyepiece
> Moon Filter + Sun Filter
> Heavy-duty Lightweight & adjustable Height Aluminum Tripod
> Accessory Tray
> Manual Included
>
> I am looking for recommendations if possible to purchase a seperate
> motor unit that will interface with software. I have not purchased
> any software and would like recommendations for that also. I have
> looked at Deepsky 2003.
>
> Please help!
>
> Gordon
>
>
> To unsubscribe from this group, send an email to:
> ASCOM-Talk-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

> I would agree for the CanHalt. In that case the issue is that
> you have to halt the focuser to find out if you can halt it.
> The other two are read-write proerties so you can test for
> implementation via (e.g.) Focuser.StepSize = Focuser.StepSize
> without needing a Can flag. Yes you need to catch errors
> (Err.Number test is easiest).

Gotcha.  Can flags should only be used for features where
there is no other way to avoid an unintended side effect.

Jon

Do any of the focusers have a variable minimum step position? If so then
it would seem to me that we need a MinStep property. The RoboFocus, for
example, has a normal minimum step of 2. For a relative focuser, for
example, its quite likely that we might start at zero at power up and go
+ve or -ve. CCDSoft (in the FocusAPI skeleton code) has +ve and -ve
limits and tries to read a minimum position from the focuser. Currently,
I'm just returning zero. That seems to me like a big fat assumption. As
the man said in Under Siege II, assumption is the mother of all, urmmm,
mistakes.

I'd really like to see someone write some wrapper classes for C++.
Trying to do calls into ASCOM drivers is horrendous at the moment. Am I
the only one using C++ to do ascom stuff?

--Tim




-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Wednesday 05 March 2003 14:32
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Focuser standard V2


BREWSTER,JON A (HP-Corvallis,ex1):
> The list below are my thoughts after ditzing with the Focuser code for

> the last couple of weeks:
>
> 1) "Link" property could be deprecated (but left in?) "Connected"
>    could be added

I have mentioned this one too... inconsistent with the existing
Connected property as used in Telescope, Link is either a noun or a
verb, so it could be the name of a property or a method. Does it mean
"link it" or "the link"? These sorts of things seem nitty I know. But if
there's a way to confuse or misinterpret someone will do so, and it's
better to close off that sort of thing in the design.

> 2) Could use CanHalt, CanStepSize, CanTemperature.  These mentioned
>    features throw errors if not implemented currently [...]

I would agree for the CanHalt. In that case the issue is that you have
to halt the focuser to find out if you can halt it. The other two are
read-write proerties so you can test for implementation via (e.g.)
Focuser.StepSize = Focuser.StepSize without needing a Can flag. Yes you
need to catch errors (Err.Number test is easiest).

> 3) TempCompAvailable could be CanTempComp.  Same as #1
>    deprecate, and add the new one

Yes, again some naming convention between drivers should be strived-for.
For better or for worse, Telescope preceded everything else and is thus
a sort of template for naming.

> 4) Description, DriverInfo, and Name would be nice.  Like
>    the scope standard.

Yes yes.

> None of this is critical.  "Name" is my highest priority.  Its hard to

> create a nice GUI if you don't have access to the friendly name.

Yeah, that's what motivated those things in Telescope. They should be
there

Any other comments re: a Focuser V2? If we can settle on this quickly
enough, we might be able to get it into the ASCOM Platform V3 in June.
Do any focuser driver authors think this is possible?

   -- Bob





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



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

Tim --

I can't comment on the focuser min-step issue...

As for wrapper classes, be careful. The ASCOM philosophy is to avoid formal
interfaces and versioning. A decision which was made to alleviate
development complexities for implementers using VB. I can discuss this with
you at length offline. The upshot is that you need to call drivers with
IDispatch and DispIDs which you get via GetIDsOfNames. C++ is by nature a
hard way to work with loosely bound components. The typical deal of using
#import generates code that has hardwired DIspIDs and GUIDs.

Someone here found out a cool way to edit ATL-generated wrappers to make
them general, I think. Anyone want to comment?

   -- Bob

I realize that C++ wasn't the primary driving force behind ASCOM and I
accept that. I haven't been doing Windows stuff for very long so I'm not
aware of all the complexities, but it seems like .NET takes away a lot
of these issues. I'm sure that's a whole other can of worms, though. C#
seems like a good compromise between VB and C++ to me.

--Tim




-----Original Message-----
From: Bob Denny [mailto:rdenny@...]
Sent: Wednesday 05 March 2003 18:17
To: ASCOM-Talk@yahoogroups.com
Subject: Re: [ASCOM] Focuser standard V2


Tim --

I can't comment on the focuser min-step issue...

As for wrapper classes, be careful. The ASCOM philosophy is to avoid
formal interfaces and versioning. A decision which was made to alleviate
development complexities for implementers using VB. I can discuss this
with you at length offline. The upshot is that you need to call drivers
with IDispatch and DispIDs which you get via GetIDsOfNames. C++ is by
nature a hard way to work with loosely bound components. The typical
deal of using #import generates code that has hardwired DIspIDs and
GUIDs.

Someone here found out a cool way to edit ATL-generated wrappers to make
them general, I think. Anyone want to comment?

   -- Bob


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



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

Bob Denny wrote:

> Someone here found out a cool way to edit ATL-generated wrappers to make
> them general, I think. Anyone want to comment?

No, that was for the MFC class wrappers.  I forget who suggested it, but
the trick was to replace the hard-coded ID's with GetIDOfNames calls.

Doug

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

Doug George
dgeorge@...

Diffraction Limited
Makers of Cyanogen Imaging Products
http://www.cyanogen.com

100 Craig Henry Drive, Unit 106,
Ottawa, Ontario, Canada, K2G 5W3

Phone:    (613) 225-2732
Fax:      (613) 225-9688

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