Hot Door CORE Forum
Using XCODE with core - Printable Version

+- Hot Door CORE Forum (http://hotdoorcore.com/forum)
+-- Forum: All forums (http://hotdoorcore.com/forum/forumdisplay.php?fid=1)
+--- Forum: Getting started (http://hotdoorcore.com/forum/forumdisplay.php?fid=6)
+--- Thread: Using XCODE with core (/showthread.php?tid=6)

Pages: 1 2 3 4


RE: Using XCODE with core - VincentDoan - 03-09-2014

Hi Garrett,

I hope you are doing well.
Am I right that for hit test, CORE does not have option to disable fill hit or handle hit like AI SDK does?
These are very important for my tool, without my tool won't be able to support major features it currently does.

Looking forward to hear your response,

Vincent


RE: Using XCODE with core - VincentDoan - 03-10-2014

Hi Garrett,

I am sorry to dump loads of questions to you, but I am really stuck right now.
I acquire the sHitTest but it does not work, so I use sAIHitTest which CORE owns and filter the hitType I need, which works OK, hovering to path object returns correctly, but when mouse down on, say an anchor, crashed with this dump which I have no clue, you the only one I know can decipher it. See 0x12477172 bad access error.

0x124770f4 <+1348> movzwl 0x1c(%edi),%eax
0x124770f8 <+1352> mov %ax,0x1c(%esi)
0x124770fc <+1356> movzwl 0x24(%edi),%eax
0x12477100 <+1360> mov %ax,0x24(%esi)
0x12477104 <+1364> movzwl 0x26(%edi),%eax
0x12477108 <+1368> mov %ax,0x26(%esi)
0x1247710c <+1372> movzwl 0x28(%edi),%eax
0x12477110 <+1376> mov %ax,0x28(%esi)
0x12477114 <+1380> movzwl 0x2a(%edi),%eax
0x12477118 <+1384> mov %ax,0x2a(%esi)
0x1247711c <+1388> mov 0x20(%esi),%ecx
0x1247711f <+1391> test %ecx,%ecx
0x12477121 <+1393> je 0x12476c2c <_ZN3hdi6plugin10Dispatcher19__updateMessageDataERKSsS3_Pv+124>
0x12477127 <+1399> mov 0x20(%edi),%edx
0x1247712a <+1402> test %edx,%edx
0x1247712c <+1404> je 0x12476c2c <_ZN3hdi6plugin10Dispatcher19__updateMessageDataERKSsS3_Pv+124>
0x12477132 <+0000> lea 0x201fb6(%ebx),%eax
0x12477138 <+0006> mov %eax,0x4(%esp)
0x1247713c <+0010> mov 0x10(%ebp),%eax
0x1247713f <+0013> mov %eax,(%esp)
0x12477142 <+0016> call 0x1266d64e <dyld_stub__ZNKSs7compareEPKc>
0x12477147 <+1431> test %eax,%eax
0x12477149 <+1433> je 0x12476c2c <_ZN3hdi6plugin10Dispatcher19__updateMessageDataERKSsS3_Pv+124>
0x1247714f <+0000> lea 0x202a46(%ebx),%eax
0x12477155 <+0006> mov %eax,0x4(%esp)
0x12477159 <+0010> mov 0x10(%ebp),%edx
0x1247715c <+0013> mov %edx,(%esp)
0x1247715f <+0016> call 0x1266d64e <dyld_stub__ZNKSs7compareEPKc>
0x12477164 <+1460> test %eax,%eax
0x12477166 <+1462> je 0x12476c2c <_ZN3hdi6plugin10Dispatcher19__updateMessageDataERKSsS3_Pv+124>
0x1247716c <+1468> mov 0x20(%esi),%edx
0x1247716f <+1471> mov 0x20(%edi),%eax
0x12477172 <+1474> movzwl (%eax),%eax //EXE_BAD_ACCESS HERE!!!!
0x12477175 <+1477> mov %ax,(%edx)
0x12477178 <+1480> mov 0x20(%esi),%edx
0x1247717b <+1483> mov 0x20(%edi),%eax
0x1247717e <+1486> mov 0x2(%eax),%eax
0x12477181 <+1489> mov %eax,0x2(%edx)
0x12477184 <+1492> mov 0x20(%esi),%edx
0x12477187 <+1495> mov 0x20(%edi),%eax
0x1247718a <+1498> mov 0x6(%eax),%eax

Also, do you have any example on setting up the annotator and annotate say a line?
I spent hours without any result other than the annotator triggers when ask to.

Please help, I am almost there!

Loads of thanks,

Vincent


RE: Using XCODE with core - VincentDoan - 03-10-2014

Another hit test update:

with only SegPointOrInteriorHitRequest set, CORE hit on in/out handle even when the handle is not visible, for example when the whole path is selected. This is not normal.

Vincent

The crash dump mentioned in previous post about hit test only occurs if the timer is active, I don't know why yet. Another thing I have found is CORE report the segment number different from what AI SDK normally would when the segment is hit.


RE: Using XCODE with core - VincentDoan - 03-10-2014

In AI SDK, cursor location is with respect to the bottom left, but CORE cursor location is with respect to top left.
Is there a reason for this change? How do I get the cursor location identical to the way AI SDK works (bottom left)?


RE: Using XCODE with core - VincentDoan - 03-10-2014

CORE does not report hit on handle once the handle is moved.
First, draw a circle, click an anchor, drag the handle, move cursor to dragged handle, CORE hit test failed to report hit.
CORE do report hit on any handle that has not been moved.
Also CORE report handle hit when the handle is not visible.

Vince


RE: Using XCODE with core - VincentDoan - 03-10-2014

My guess is CORE changes AI default coordinate system.
The cursor, the hit point and the art object locations are all referenced to top left of active art board.
If I use sPath to get the path object's location, it returns points in referenced to top left but with y negative below the top left corner.
I am figuring out a way to remap all this if my existing is to work with CORE.


RE: Using XCODE with core - garrett - 03-10-2014

Wow, this is a lot of questions, and this thread is getting too large. I will try to answer all of them for you here, but in the future can you start a new thread for each individual issue you're having? That will make it easier to keep track of things. Thanks.

Your question/concern about tool tracking and/or hit tests wasn't very clear. Are you having trouble receiving tool messages, or just performing hit tests?

CORE does not use Illustrator's AIHitTestSuite at all. We have a custom implementation of hit testing in the hdi::core::HitData class that allows for hit tests to occur off-screen, which AIHitTestSuite does not allow. We also wanted to simplify some of the over-complications and annoyances of Illustrator's hit testing. If you prefer Illustrator's hit tests over CORE's, then simply use AIHitTestSuite as you normally would.

CORE currently does nothing with AIArtSetSuite, as we have not needed it in any of our own plugins. I am also somewhat unfamiliar with that suite because we haven't needed it. There should be no reason for CORE to interfere with the operation of the suite, unless AIArtSetSuite-related messages are being improperly handled by CORE's event dispatcher. I will have to discuss this situation further with Brendon.

The vast majority of modern graphics programming environments utilize an inverted first quadrant of the Cartesian plane, so in CORE we made the choice to "flip" all of Illustrator's coordinates to match. This is to say that in most environments, x-axis values increase as you go left-to-right, and y-axis values increase as you go top-to-bottom. For some reason, Adobe made the decision to utilize a true first quadrant, as their y-axis increases going bottom-to-top. If you need to convert a hdi::core::ArtboardPoint for use with an Illustrator suite, then simply flip the sign of the y-axis value. If you do this a lot, then a macro would probably be a big help.

Here is a quick example for an annotator in the Skeleton sample:
Code:
void skel::Plugin::startup()
{
    this->__corePlug->dispatcher()->registerAnnotator(
        hdi::core::Annotator(
            "MY_SAMPLE_ANNOTATOR_ID",
            HDI_CORE_CALLBACK(skel::Plugin, this, __annotate)
        )
    );
}

void skel::Plugin::__annotate()
{
    hdi::core::annotate::line(
        hdi::core::Point(10.0, 10.0),
        hdi::core::Point(20.0, 20.0)
    );
}

With regards to your crash, it's really hard to say without seeing some sample code that exhibits the problem. However, it seems to be event dispatching-related, so an object you were pointing to in a callback might have been deleted (so a crash occurred when its member function was dereferenced). Otherwise, you might have modified a member of the hdi::core:Big Grinispatcher class somehow, and during message data cleanup it dereferenced a bad pointer. I would start looking for these types of situations, and provide us with some sample code that exhibits the issue if possible. Of course, the problem might go away when you switch to AIHitTestSuite.

EDIT: We can probably get version 0.5.1 of CORE out this week, but it might have to wait for next week.

Thanks for the feedback.


RE: Using XCODE with core - Rick Johnson - 04-06-2016

(02-27-2014, 01:35 PM)garrett Wrote: I am unaware of any programs to convert from *.cur to the Mac's CURS resource format. However, the CORE API works with *.png files, so you could easily switch to the hdi::core::Cursor class.

This doesn't address Mac CURS resources, but I found a free ($5 donation requested) Photoshop plugin at Telegraphics.com that opens and saves Windows .ICO and .CUR files so you can save them as PNG, and there's a Mac version, too. Since I can't find a way to open and salvage icons from my .rsrc resource files, this is a lifesaver for moving old Windows projects to Mac/Win CORE projects.

-- Rick