My approach. The core is the engine. - page 98

New comment
 
As a tip on how you can do this, look at the structure of a zip archive. It consists of simple structures and data. A similar structure could be great for transferring data. Note that there is not a single line in the zip archive, which does not prevent it from perfectly displaying a miniature filesystem with hundreds of files with different names.
 
Vasiliy Sokolov:
As a hint how to do it, look at zip archive structure. It consists of simple structures and data. A similar structure could work well for data transfer. Note that there is not a single line in the zip archive, which does not prevent it from perfectly displaying a miniature filesystem with hundreds of files with different names.

I agree with your professional view of the task. Byte transfer looks more serious than string transfer via MT objects.

The question is how feasible it is to implement.

The size and types of data to be transferred are not known beforehand. How to implement it?

 
Реter Konow:

I agree with your professional view of the task. Byte transfer looks more serious than string transfer via MT objects.

The question is how feasible it is to implement.

The size and types of data to be transferred are not known beforehand. How to implement union?

It's possible.

Please study the structure of your zip in detail. An understanding will come. The size of the packed files before packing is not known. The names of the files may be of different lengths. The number of files can also be very different. Regardless, the zip represents a strictly-typed set of finite structures referencing the data.

Once you know which structures you need to work with, there's no problem with union, because union is simply a representation of those structures as bytes.

 
Vasiliy Sokolov:

Possible.

Study the structure of the zip in detail. An understanding will come. The size of the packed files before packing is unknown there. File names can be of many different lengths. The number of files can also be very different. Regardless, the zip represents a strictly-typed set of finite structures referencing the data.

When you figure out what structures you need to work with, you won't have any problems because you can simply represent these structures as bytes.

Okay, but why don't you do without a union, for example?

At each event, the EA collects a message string, which includes all changed parameters and their values of all types. Then we convert this string to a byte array using StringToChar, and write it into a resource. Then, we do the reverse unpacking.

Initially, I had imagined such a solution with the resource. But, it needs to assemble and split the string.

 
You can't do without a resource in your solution anyway. So the question is how to get around parsing the string. You think it's possible. I honestly doubt it. But I wouldn't rule it out...
 
Реter Konow:

OK, but why not do without union, for example.

At each event, the EA collects a message string including all changed parameters and their values of all types. Then we convert this string to a byte array using StringToChar, and write it into a resource. Then, we do the reverse unpacking.

Initially, I had imagined such a solution with the resource. But, it needs assembly and splitting of the string.

Union is a simultaneous representation of structures as bytes or int, which is the same thing. Union seems to project structures onto a byte array while the byte array is simultaneously a set of structures. If the resource is an int array, there is no need to perform the additional procedure of converting an array of bytes into an array of structures and the reverse operation. This saves time.

p.s. With this scheme, the message source doesn't copy data into the resource, it changes the data directly, and these changes appear in the resource at once. So, instead of endless conversions of strings to arrays, and arrays to strings with subsequent parsing, you work with the data directly. This data is copied only to recipients using ResourceReadImage.

 
Vasiliy Sokolov:

Union is the simultaneous representation of structures as bytes or int, which is the same thing. Union kind of projects structures onto a byte array, and a byte array is simultaneously a set of structures. If the resource is an int array, there is no need to perform the additional procedure of converting an array of bytes into an array of structures and the reverse operation. It saves time.

I'll have to think about it... Maybe you're right, and it's possible to implement with union.

For example, if every setting of a parameter value, would convert that value to an array of bytes. More precisely, all user parameters, should belong to the union. Then, their copy reflected in bytes will be immediately available for writing to the resource.

 
Реter Konow:

For example, if each setting of a parameter value, will convert that value to an array of bytes. More precisely, all user parameters must belong to the union. Then, their byte-reflected copy would be immediately available for writing to the resource.

Yes, exactly, I already replied in ps to the previous post, when you wrote it :) I.e. we're not working with long copying and conversion, but exactly mapping.

 
In short, every time a user parameter value is changed, the value must be converted to the value of a unit variable and immediately saved to a common byte array, which can then be converted to uint and written to a resource.
 
Vasiliy Sokolov:

Yes, exactly, I already replied in the ps to the previous post when you wrote this:) I.e. we're not working with long copying and converting, but exactly mapping.

OK, but what about texts?

They must be converted to bytes viaStringToChar(). You can't use union, right?

1...919293949596979899100101102103104105...184
New comment
Reason: