3D Modeling

[polisetty]

I have derived a memory-based FileInterface object from BinaryFile to be used with api_restore_entity_list_file, following the sample code from the documentation. It seems to be working fine except for cross-platform files. For instance binary files saved on Windows, return error "operation unsuccessful" when restored on Mac Os X and vice-versa. Has anybody else run into this issue before?

I noticed that BinaryFile has data members like big_endian, swap and read_long_size. Does the user need to set any of these fields?

Thanks for any help.

Hari

Code:

// define a simple memory-based FileInterface class

class MemoryFile : public BinaryFile {
private:
     char * name; // The name of the part.
     char * data; // The pointer to the data.
     size_t size; // The current size of the data block.
     FilePosition position; // Current read/write position.
public:
     MemoryFile( char * in_name = NULL ) 
          : name(NULL), data(NULL), size(0), position(0) {
          if( in_name != NULL ) // Copy the input name.
               name = ACIS_STRDUP( in_name);
     }
     ~MemoryFile() {
          if( name != NULL )
               ACIS_FREE( name); // Release the memory
          if( data != NULL )
               ACIS_FREE( data );
          name = NULL; data = NULL; size = 0; position = 0;
     }
     size_t read( void *buffer, size_t length, logical swap ) {
          if( size == 0 )
               length = 0; // Nothing to read.
          if( length > size - position ) // Do not read 
               length = size - position; // passed the end. 
          if( length ) {
               memcpy( buffer, data + position, length );
               position += length; // Update read position.
          }
          return length;
     }
     void write( const void *buffer, size_t length, logical swap ) {
          if( size == 0 ) // Initial call, get some memory.
               data = (char*) ACIS_MALLOC( size = 1024 );
          if( length > size - position )
               data = (char*) // We need more memory.
                    ACIS_SAFE_REALLOC( data, size, size *= 2 );
          if( length ) {
               memcpy( data + position, buffer, length );
               position += length; // Update the write position.
          }
     }
     FilePosition set_mark() { return position; }
     FilePosition goto_mark( FilePosition file_pos ) {
          if( file_pos == -1 || file_pos > size )
               return position = size; // Set to end of data.
          else
               return position = file_pos;
     }
};

 

[SERGEY]

Hi,

Check the "binary_format" option in documentation - may be it helps;

Sergey

[polisetty]

Hi sergey,

Thanks for the suggestion.

As per the docs, 'binary_format' controls the format to use when saving.

'binary_read_format' is the option that controls the format to use when reading.

Anyway I tried both and they didn't make any difference with api_restore_entity_list_file.

I still get the same error.

api_restore_entity_list works fine however without setting any options.

So this looks like an acis bug to me.

Any thoughts on this Spatial Tech Support?

Thanks,

Hari

[Stacey]

Hi Polisetty,

You mention in your last message that you tried the binary_target method, but you didn't mention the value you tried.  I am not sure if this is the same issue, but there was an earlier issue in R17 with restoring attributes from binary files created with certain read_format settings.  This inconsistency can be avoided in R17 by implementing binary_target virtual method as FALSE.  If you have implemented this virtual method as false and are still seeing the issue, please let us know and we will investigate further.

Note that these issues are fixed in R18 (released this week!) and that the binary_format and binary_read_format methods are no longer necessary.  They have been deprecated.  Please see the R18 release notes for more information.

Best Regards,

Stacey

[polisetty]

Hello Stacey,

I've migrated to R18 today and I'm still seeing the same error.

By the way, I did not mention anything about using binary_target method in my posts.

As for the binary_format and binary_read_format methods, I have not used them to begin with.

My original question was if I had to do anything else in addition to the sample code from the docs to get this api to work properly across platforms.

Please let me know if you need anything else in order to investigate thus issue further.

Thanks,

Hari

[polisetty]

Hello Stacey,

Can you please let me know if this issue is being looked into?

Or do I need to submit this as a bug report through the Online Support channel?

Thanks,

Hari Polisetty

[Stacey]

Hi Polisetty,

We are taking a look at it and I will update you very soon.

Best Regards,
Stacey

[Jeff]

Hi Hari

ACIS always expects to write data in the native format of the current machine. (The ability to target other formats has long been deprecated.) The BinaryFile write method therefore does not have to take its logical swap argument into consideration. The read method on the other hand does have to. The need to swap is determined early on in the restore process, when the ACIS version information of the input data is evaluated. Subsequent calls to the read method then must swap the input data when the following three conditions are all true:

1) when the logical need_swap is true (or is_byte_swapping() returns true)

2) when the logical swap input argument is true

3) when the size_t length input argument is less than 9 bytes

This would look something like this:

if( swap && need_swap && length <= 8 ) {

// swap the input data

}

The simple memory based FileInterface example does not take cross-platform issues into consideration.

Hope this helps,

Jeff

[polisetty]

Hi Jeff,

That worked.

I suggest that this information be included in the Documentation.

I t could save a lot of time for the developers.

Thanks for the help.

Hari