APIElementEventHandlerProc bug?

[ReignBough]

I am doing an add-on where I will get the area of the zone when it was modified. I used the element event handler and handled the following events:

APINotifyElement_Change
APINotifyElement_Edit
APINotifyElement_Undo_Modified
APINotifyElement_Redo_Modified

I am also using the quantities to get the area (ACAPI_Element_GetQuantities()).

But the value of the area when APINotifyElement_Undo_Modified was called, the value of the saved area is the same as those that are in quantities.

EXAMPLE:

ORIGINAL_AREA = 100

APINotifyElement_Edit is called:

ORIGINAL_AREA = 100
QUANTITY_AREA = 150 (let say that this is the "new" area)

I save the new value:

ORIGINAL_AREA = 150

APINotifyElement_Undo_Modified is called:

ORIGINAL_AREA = 150
QUANTITY_AREA = 150

Since it is undo, I am expecting that quantity value should be 100.

Is this a bug or should the undo value is located on different structure?

[ReignBough]

I found a <del>hack</del> temporary solution to this problem.

I created a global variable where i save the value of API_NotifyElementType. I will then process it on APINotifyElement_EndEvents.

GSErrCode __ACENV_CALL MyElemObserver(const API_NotifyElementType* iElemType)
{
	switch (iElemType->notifID)
	{
	// ...other notify ids...
	case APINotifyElement_EndEvents:
		switch (g_LastEvent.notifID)
		{
		case APINotifyElement_Undo_Modified:	//<== handle here
		case APINotifyElement_Redo_Modified:	//<== handle here
			Foo(g_LastEvent.elemHead.guid);
			break;
		}
		break;
	}
	g_LastEvent = *iElemType;	//<== save here
	return NoError;
};

[Ralph Wessel]

ReignBough wrote:
I found a hack to this problem.
I created a global variable where i save the value of API_NotifyElementType. I will then process it on APINotifyElement_EndEvents.

That's not a hack. The begin/end structure of the notification process allows you to cache all the elements involved in a transaction and batch process them at the end.