"Vpoint" not always working

[kpennell]

The following code:

(command "vpoint" "-1,-1,1")

Sometimes works and sometimes not.  I can't seem to track down any kind of trend or behavior to pass along.  Except this one.  In one drawing, for one user, it works.  The same drawing for another user, it doesn't work.

And...

For a particular user, it will work in one drawing, but in another drawing, it will not work.

The view is a standard isometric view that we use in the office.  But sometimes is gives a view looking east (to the positive "x").  Sometimes, it's down.  Very wierd.

Any suggestions?

Thanks,

KP

[wispoxy]

How to programmatically mimic the vpoint command?

By Xiaodong Liang

Issue

I use the following code to change the view:

  ads_point pt = {1,1,1};

  acedCommand(RTSTR, "vpoint", RTSTR, "non",

              RT3DPOINT, pt, RTNONE);

Why doesn't the following ARX code change the view?

AcDbViewportTable *pTable;

acdbHostApplicationServices()->workingDatabase()->getViewportTable(

        pTable,

        AcDb::kForRead));   

AcDbViewportTableRecord *pRecord;

pTable->getAt("*ACTIVE", pRecord, AcDb::kForWrite);

AcGeVector3d direction(1, 1, 1);

pRecord->setViewDirection(direction);

pRecord->close();

pTable->close();

Solution

When using ARXDBG to check the result of your code, the viewdir is changed for the active viewport table record. Note that viewdir system variable is not changed and the actual view does not change, either.

What you can do is to set up a AcDbViewTableRecord object, then use acedSetCurrentView() to set the current view according to the object's settings.

The following code mimics what the VPOINT command does:

static void simulateVpointCmd()

{

    AcDbViewportTableRecordPointer pRecord(

        acedActiveViewportId(),AcDb::kForWrite );

    Acad::ErrorStatus es = pRecord.openStatus();

    assert(es == Acad::eOk);

    pRecord->setViewDirection(AcGeVector3d(1,1,1));

    AcDbViewTableRecord vtr;

    vtr.setBackClipDistance(pRecord->backClipDistance());

    vtr.setBackClipEnabled(pRecord->backClipEnabled());

    vtr.setElevation(pRecord->elevation());

    vtr.setFrontClipAtEye(pRecord->frontClipAtEye());

    vtr.setFrontClipDistance(pRecord->frontClipDistance());

    vtr.setLensLength(pRecord->lensLength());

    vtr.setPerspectiveEnabled(pRecord->perspectiveEnabled());

    vtr.setRenderMode(pRecord->renderMode());

    vtr.setTarget(pRecord->target());

    vtr.setUcs(pRecord->ucsName());

    vtr.setViewDirection(pRecord->viewDirection());

    // viewtwist in vpoint is always 0

    // if you set it correctly, you can't get a result

    // that is similar to vpoint's

    vtr.setViewTwist(pRecord->viewTwist());

    vtr.setCenterPoint(pRecord->centerPoint());

    vtr.setHeight(pRecord->height());

    vtr.setWidth(pRecord->width());

    acedSetCurrentView(&vtr, NULL);

    // this is tweaking it to make it look like the result of vpoint cmd

    acedCommand(RTSTR, L"zoom", RTSTR, L"extents", RTNONE);

}

[Kent1Cooper · Accepted solution]

The possibility that occurs to me that may explain the variant nature of the problem is that your Users may sometimes have running Object Snap modes on that are latching onto something.  Try:

(command "vpoint" "_none" "-1,-1,1")

If that doesn't fix it, I don't have any better ideas as to the reason, but you might instead try ViewsNoZoom.lsp, available here.  Its primary purpose [as the name implies] was to not Zoom to the Extents every time you change a view direction, and have to Zoom back in to where you were.  In order to do that, it uses the DVIEW command rather than VPOINT, so it may get around your problem, whatever is causing it.  The equivalent to your -1,-1,1 Vpoint direction would be the VISWO command [= View, Isometric, SouthWest, Overhead].  Note that it also covers the isometric view directions from underneath, which AutoCAD's Views Toolbar icons don't.

[kpennell]

That seems to be the problem.  I'm getting consistent successful results since I've specified the "none" osnap on applying the viewsettings.

Thanks,

KP

[Kent1Cooper]

---

@kpennell wrote:

That seems to be the problem.  I'm getting consistent successful results since I've specified the "none" osnap on applying the viewsettings.

Thanks,

KP

---

You're welcome.  Object Snap is always the first thing to check whenever anything happens differently than you expect in any kind of positionally- or directionally-related sense.

[kpennell]

also good advice.