Custom Query (35 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (19 - 21 of 35)

1 2 3 4 5 6 7 8 9 10 11 12
Ticket Resolution Summary Owner Reporter
#19 fixed Wrong VTABLE IPersistStream jasper

Reported by jasper, 8 years ago.

Description

Decompiling the interface, I see

#region Assembly CAPE-OPENv1-1-0.dll, v1.1.0.0 C:\Program Files (x86)\Common Files\CAPE-OPEN\Reference Assemblies\CAPE-OPENv1-1-0.dll #endregion

using System; using System.Runtime.InteropServices; using System.Runtime.InteropServices.ComTypes;

namespace CAPEOPEN {

[ComVisible(false)] [Guid("00000109-0000-0000-C000-000000000046")] [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)] public interface IPersistStream : IPersist {

void GetSizeMax(out long pcbSize); int IsDirty(); void Load(IStream pStm); void Save(IStream pStm, bool fClearDirty);

}

}

The propert VTABLE order is {IsDirty,Load,Save,GetSizeMax}. As a result attempting to call Save actually calls GetSizeMax in the above interface.

#20 wontfix Marshal.ReleaseComObject michelpons jasper

Reported by jasper, 8 years ago.

Description

Documentation should mention that for .NET implementations, all external objects must be released using Marshal.ReleaseComObject when they go out of scope. Otherwise .NET will not release the COM objects until GC is invoked, which causes external references to temporary objects to linger, and causes objects to be locked passed Terminate. It should be mentioned that Marshal.ReleaseComObject will render a COM object inaccessible, so this should not be done on a particular interface to a COM object while other interfaces to the same object must remain valid. Example: IPersistStreamSave should Marshal.ReleaseComObject the stream pointer within the routine. Example: objects connected to unit ports should Marshal.ReleaseComObject at Disconnect and Terminate.

#21 fixed Install fails with message: "The System cannot open the device or file specified" michaelhalloran

Reported by michaelhalloran, 7 years ago.

Description

A user was able to install from one directory but not another. The explanation turned out to be that for the directory that failed only the user had rwx permission, but not SYSTEM and the Administrators group. It seems that msiexec needs SYSTEM or admin permission in the source directory to be able to install successfully.

1 2 3 4 5 6 7 8 9 10 11 12
Note: See TracQuery for help on using queries.