Yes, as long as you are using the solve sync, it will end up being accurate. I thought one of the earlier suggestions was to not do solve sync on the target since … if you did a ‘blind slew’ and just cut and paste the coordinates into the target with the new button and then did a solve and sync - why not just blind slew, solve, sync and populate the coordinates into the sequence with the button on the solver?
There are a series of requests like this around at the moment. Users with special cases wanting an additional button to do something that’s already available albeit in a slightly more complex way, such as using a context menu.
If they were all implemented then the SGP UI would become even more complex - a sea of buttons, mostly implementing things that are already available.
If you have a special requirement that’s not in the normal path that SGP is designed for then I think you need to accept that you may need to do things in a slightly more complex way.
In this case using a couple of context menus to copy and past a position isn’t very onerous, it only takes a few seconds.
Chris - I actually agree with your sentiments and this is largely academic for me. I have a number of critical issues that have not been addressed and the result is that most of SGP functionality is not usable to me. So in this thread I am simply acknowledging that it is a feature that has merit that should be appropriately prioritized with all the other feature requests.
When even a small set of users have a critical issue that has no workaround - I personally would give that high priority.
So there is really no need for any non-developer to lecture users on what they should and should not request. The developers have their own system for deciding what to work on - and I don’t know what the algorithm is.
I think the users should request what they feel would be valuable to them and see if it gets priority. In this case the feature was hard to explain as something desirable and useful - but I think it is. And it is just one button - as opposed to elaborate support for new hardware that few people own - that does get priority for whatever reason.
Frank
I don’t see that Chris is lecturing - he’s making a general point that the nature of software development implies some constraints and that it is a compromise of keeping the UI uncluttered and serving user needs.
Sometimes it takes a little bending on the part of the user and an alternative and equally simple workflow to accomplish the same thing.
I think Ken and Jared have managed that balance very well over the last few years.
Agree that this is also a matter of perspective, I wouldn’t have thought my use case was unique. I have been thinking about it and the other easy gain is for those of us using autofocus. It makes even more sense when you consider this as it further simplifies and “ad-hoc” workflow as by populating the target in this manner, SGP and the plate solve engine will focus the camera sync and re-center the mount automatically.
I would think that “Use current” would be a label for the button in the target setting window, which you could then use the “Center Now” option or just add to the sequence.
I think, short of the feature being added, this may be the way I’ll operate as it give me a way of transferring the coordinates and re-slewing without switching back and forward between applications.
Maybe the additional feature button would make more sense being included in the focus target module, where the “Set Target Position” would set the target position or add a target to the sequence. Or even an additional button here “Copy Target position to Target position” 
That’s not a label for a button that would cause any confusion at all, right? * SIC*
Remember this is for a setup for a single target run on a mobile rig with no external connectivity.
Buzz, it’s not quite there as I’d then have to re-slew and repeat the process unfortunately, I’m trying to reduce the manual intervention.
Got it! If I’m that close I can nudge the frame manually, Can’t say I’ve either encountered or noticed this before…
I struggled with the same thing as the OP when first using SGP as I also had previously used a combination of CdC & Astrotortilla to get the scope pointing at the target. I also posted a request for the same facility: Request for a facility to use the current mount position as the target - Feature Requests - Main Sequence Software
In the thread I also mentioned the similarity with the existing Target Markers function.
However, Chris’s revelation that you can copy and paste the coordinates from CdC in a single operation makes things a lot simpler - I didn’t realise you could do that. I think this should solve the issue from my point of view, as I should be able to do everything from within SGP after the copying of the coordinates in CdC.
Am I right in thinking though that you must have CdC set up to report the coordinates in Astrometric J2000?
Ok,
So I guess after much useful input, and thanks to all who have. There are 2 ways to go about this, first would be to have a feature added whereby the Frame and focus target could be used as the imaging target using a copy of sorts and maybe changing the terminology a little so it wouldn’t be as confusing as “Set Target as Target”. I’ve yet to try the direct copy from CDC, however this should get those of us who operate this way out of trouble, however I still maintain that there would be value in adding or changing the behaviour of the frame and focus target setting window as If you are slewing to the target anyway with target markers, wouldn’t that be the target you are interested in adding to your sequence?
Anders