Detecting a Cached Saved View Attachment in MicroStation CONNECT

Peter Jones said:

I have some legacy VBA code

Any variable that is a C pointer must be declared as LongPtr in VBA 7.

Peter Jones said:

Private Declare PtrSafe Function mdlRefFile_getInfo Lib "stdmdlbltin.dll" (ByVal modelRef As LongLong) As LongLong

Private Declare PtrSafe Function mdlRefFile_getInfo Lib "stdmdlbltin.dll" (ByVal modelRef As LongPtr) As LongPtr

Peter Jones said:

The v8i code generates an error "expected struct/union name" when running in CONNECT

struct RefDisplayFlags is defined in C++ header file DgnAttachment.h.  However, I don't see where it's used: it is not a member of class DgnAttachment.  LIkewise, I see no methods in class DgnAttachment to do with display or hidden line caching.

Hi Jon,

Thanks for getting back to me!

The MSDN Article states that it transforms to a LongLong in 64bit environments, so it should function as written I would have thought?

I've amended the code to LongPtr nevertheless.

As for the struct - if it's defined then it should be accessible, should it not?

The software allows for caching of dynamic views, which is indicative that it must be available through some means, do you have any suggestions of other places to hunt?

Attempting to access the DgnAttachment struct with any members that are listed in the documentation (e.g. IsMissingFile() ) results in the same error: "expected struct/union name" which makes me think it's not publicly available.

Is there documentation which I am missing that lists the publicly available structs for CExpression?

In fact any further documentation on CExpression would be helpful!

Additionally, I was unable to find any published documentation or articles that mentioned the referenceFile struct, yet it is accessible in v8i - is there a resource I am missing or should be looking in?

Peter Jones said:

The MSDN Article states that it transforms to a LongLong in 64bit environments

Yes -- a 64-bit integer.

Peter Jones said:

it should function as written I would have thought?

It does, but probably not for the reason you think.

C libraries, such as MDL and Win32, sprinkle pointers liberally throughout their APIs.  For MicroStation V8, a 32-bit app, pointers are 32-bit, which is a Long in VBA 6.  For MicroStation CONNECT, as 64-bit app, pointers are 64-bit.  In other words, a pointer is a 64-bit integer: a LongLong in VBA 7.

It's not incorrect to write LongLong, but it is semantically misleading when the variable is a C pointer.  LongPtr expresses accurately what the variable is intended for.

Peter Jones said:

As for the struct - if it's defined then it should be accessible, should it not?

I wouldn't bank on it.  We usually have to work out the equivalent UDT in VBA.  And, even if it is defined, there's no way that I can see to fill the struct with data from an Attachment.

Peter Jones said:

Is there documentation which I am missing that lists the publicly available structs for CExpression?

No.  One suggestion is to record a VBA macro while you twiddle the settings in the References dialog.  Examine the macro recording, which sometimes reveals C expressions generated to manipulate application variables.

Peter Jones said:

any further documentation on CExpression would be helpful!

It would, I agree.

Peter Jones said:

I was unable to find any published documentation or articles that mentioned the referenceFile struct, yet it is accessible in v8i

Not everything made it into the CONNECT API.  I doubt that it's a deliberate omission, and your request may be the first time someone has sought to use it.  Maybe Robert Hook can advise?

Hi Jon,

Thanks again!

So realistically then I'm out of luck?

Cheers,

PJ

Hi Peter Jones,

Jon Summers has provided some very experienced and well-guided advice for the current path of customization you have chosen/have to take.

For MicroStation VBA if the VBA/COM APIs do not provide the functionality needed, then (as Jon mentions) using the MicroStation VBA or Bentley Macro Recorder(s) are often the next best step to gain insights and reliable path forward.  If none available the next step (especially for new/beginning API developers) would be to determine if any product Key-ins exist that may produce the desired results.  Sometimes key-ins may take some time to identify, may not exist at all, and if/when found and implemented are likely to seem obscure/strange to most future VBA API developers yet are a viable option to work until a better fit solution can be created (or required). Similarly, extending MicroStation VBA code with (Declare) MDL function calls is also likely to look obscure to a future VBA developers and can be fraught with implementation issues, testing and/or not being able to implement due to API implementation specifics, or (Microsoft or Bentley) incompatibilities when attempting to cross native, managed, or COM; memory and runtime boundaries.

So, imho and given the above...

First suggestion:

From what I can tell an Attachment's previous display.flags.hiddenLineCaching was migrated internally to using a public enum of ProxyCachingOption that I do not see a direct public API accessor for.  The closest and possibly easiest way to access this specific item would be use a VBA Property Handler on the VBA attachment object and see if you can locate a "Visible Edge Display" property and value.

Additional suggestion:

Since you appear to be doing and have a fair/significant amount and need to access the MDL API, why not consider taking some time to learn and create a more robust and reliable custom MDL "helper application".  This path would certainly provide more: direct, performant, reliable and easily debuggable MDL code/functionality; that can be called from any/many custom VBA applications via your own simple wrapper exported function calls that can survive crossing VBA/COM, native and manage code boundaries via your own custom app key-ins, connections, etc.?  Doing also best ensure consistent access and a desired clean separation between APIs and Interfaces/Implementations.

HTH,
Bob

Hi Bob,

Thanks for your reply - I've tried the Key-ins, Recording, and Property Handler to no avail.

I'm going down the road of writing a wrapper, but I'm not making much headway.

I can call the function from VBA but when debugging is VS2017 I can see that my arguments are not coming through.

At first I tried to use MdlModelRefP to get a pointer to the Attachment, then pass it through to get the DgnModelP members.

This method gave me memory exceptions (in the region of 0x00000040).

Now I'm simply trying to pass through a string but all I get is a null-terminated empty string (i.e. sRefName = "").

It seems that none of my arguments to my wrapper function are being passed to the body of the wrapper method correctly.

Additionally the Debug.Print call works properly (true / false), so at least that makes it back to VBA.

At the moment I'm just trying to match the name of reference passed as an argument to the name of a reference that is in the DgnAttachmentsCP array (there's only one reference in my test file) as a test to see if I can get anything working. A pointer would be ideal as it would save scanning the references in C++ and would allow me to cast it directly to DgnAttachmentCP to access those members.

I've put in my code in VBA and C++ below.

Is there documentation on how to write these wrappers?

It builds successfully and I can break at my wrapper in VS2017 and step through the code, the communication between VBA and the wrapper just seems broken.

VBA:

Private Declare PtrSafe Function mdl2vbaTest_RefP Lib "vba2mdl.dll" (ByVal sRefName As String) as Boolean

Sub mdlfromvba()

Dim oAtt As Attachment

For Each oAtt In ActiveModelReference.Attachments
   Debug.Print mdl2vbaTest_RefP(oAtt.AttachName)
Next oAtt

End Sub

C++ (This is an excerpt, I can post the rest if needed). For the sRefName argument variable I've tried WCharP, WChar, wchar_t *, char *, all come through empty (or not at all).

extern "C" DLLEXPORT bool __stdcall mdl2vbaTest_RefP
(
	WCharCP sRefName
)
	{
	//Do something

	if (!sRefName)
	{
		return false;
	}
	
	DgnModelP model = ISessionMgr::GetActiveDgnModelP();
	
	if (model->GetDgnAttachmentsCP() != NULL)
	{
		for each (DgnAttachmentCP attachment in *model->GetDgnAttachmentsCP())
		{
			if (sRefName == attachment->GetAttachFileName())
			{
				mdlOutput_messageCenter(DgnPlatform::OutputMessagePriority::Info, attachment->GetAttachFileName().c_str(), attachment->GetAttachFileName().c_str(), DgnPlatform::OutputMessageAlert::None);
				return true;
			}
		}
	}
	
	return false;
	}

Peter Jones said:

I can call the function from VBA

Private Declare PtrSafe Function mdl2vbaTest_RefP Lib "vba2mdl.dll" (ByVal sRefName As String)

You're passing a VBA String to a C-style function that expects a NULL-terminated array of wchar_t.  That won't work.  You need to read about Microsoft's various types of string in C and VBA.

This article should give you some hints about string conversion between C and VBA.  Pay attention to the StrPtr() function.

There are some things for which we should be grateful: MDL in V8 had the MSWideChar data type that was only used in, AFAIK, two functions.  MicroStation CONNECT is mostly Unicode, with good support in the API.  That data type has vanished.

Peter Jones said:

I can call the function from VBA

Private Declare PtrSafe Function mdl2vbaTest_RefP Lib "vba2mdl.dll" (ByVal sRefName As String)

You're passing a VBA String to a C-style function that expects a NULL-terminated array of wchar_t.  That won't work.  You need to read about Microsoft's various types of string in C and VBA.

This article should give you some hints about string conversion between C and VBA.  Pay attention to the StrPtr() function.

There are some things for which we should be grateful: MDL in V8 had the MSWideChar data type that was only used in, AFAIK, two functions.  MicroStation CONNECT is mostly Unicode, with good support in the API.  That data type has vanished.

Hi John,

Thanks - I did wonder what the expected type for C would be and I couldn't find any information on it with my google foo.

I still can't figure out why the pointer (passed through as LongPtr) from MdlModelRefP results in garbage. I'll keep looking!

Edit: Back to my original problem - I can see an enum "ProxyCacheStatus" as a member of DgnPlatform - the documentation states that it is "Returned by GetProxyCacheStatus to indicate the status of the ProxyCache of this DgnAttachment".

That's exactly what I'm looking for, however doing a search on the documentation and the contents of all of the include files turns up nothing for GetProxyCacheStatus - I can't find the function anywhere - does that mean it's simply not there?

Thanks,

PJ

Hi Peter,

I'm facing the same problem, did you find any way to sort it out? Thanks

Hi Andrea,

Andrea de Poda said:

I'm facing the same problem

What problem exactly? Originally discussed problem with cached view attachment detection, or the problem discussed later in this thread how to pass data/pointers between native and COM?

Because this discussion is 4 years old, I recommend to ask in a new post, specify used product and its exact version, and also to include a link to this discussion.

Personally I think there is still no way how to obtain information about cached attachment, because I do not see any use of ProxyCacheStatus in C++ API.

With regards,

  Jan