I don't see the reason for this discussion, because coderJeff has made it pretty clear,
that he wants it, as in your option 1).

Btw: I'll support him on that, all the way ...

dodicat wrote:There is a problem with pointers fields though, but that is another story.

Since, SizeOf(Integer) = SizeOf(Any Ptr), we're dealing with the same problem here.
That is: without conversion (implicit or explicit) to Long/Integer<32>.

Surely an enum is only a shortcut to integer<32> constants, giving then names. No, it is a shortcut to Integer = 64 bit in FBC 64 (your assumption is only valid for FBC 32). As also confirmed by D.J.Peters (Joshy) and fxm. Saving to file and retrieving from file requires only to remember a 32 bit v...

No problem, nobody is perfect ... (not even robots, when not properly maintained).

In order to explain things, relying on 'implicit conversions ' is pointless, because: 'implicit' means also 'not visible' . That is the main reason for writing it: 'explicit' and therefore clearly 'visible' . (by reading the code, it's absolutely obvious, what exactly happens ...) fxm, what you call...

Surely if .shape is a long, it takes on the values of 1, 2 or 3, and that is it, writing to a file or not. Yes, and No ... meaning: Long in the Type, all okay -- but -- the original question was, however: Enum in the Type (Integer), causing incomatibility, when written to file and thereafter opened...

The CLng() would be used in a constructor of the Type: Enum Shapes Circle = 1 ' IMO not a good idea, to use a FB KeyWord square triangle End Enum Type Block As Long Shape Declare Constructor(ByVal rhs As Shapes) End Type Constructor Block(ByVal rhs As Shapes) This.Shape = CLng(rhs) End Const...

A Enum's Data-Type is always Integer (and therefore, of Ptr size).
4 bytes in FBC 32, 8 bytes in FBC 64.

It should therefore not be used inside a Type (UDT), for read/write to/from file.
You could cast it to Long, inside the Type. CLng(...)

ppf wrote:Topic can be marked as Solved.

Only you can do that, by editing the first posts title with: (solved).
In case of a longer title, as here, it might be better to prepend (instead of appending).

@admin, clould you please stop the "compression-troll" from further posting? It is really nothing more than annoying, to read about "how to go in circles" in a never ending story. He by now seems to think, he can get away with his "daily, pointless blog-posts". (It's no...

I may follow-up with actual bug reports; even if just for myself, it's nice to have a ticket to track. I already have one open on SourceForge: #898 --- DirectX - Driver not working in FBC x64 (WIN) @macko17, that's excellent! fb gfxlib's DirectX driver now initializes for me on Win7 64-bit. Nice! C...

It is also from the FBC 32 bit, only days ... Therefore, I've tested it (q & d -- hack) if it still works, in principle. Just as a demo, how to load the DLL and access one single Function within. (I'd never use it that way. I'd split it into a static Lib, which the .exe loads.) LabJack_U12-first...

Hi Ms. Swiss, <-- MrSwiss please (I'm not Miss Switzerland ;-) ) Re: the below, can you share any FB code you've written to use your LabJack U12? Sorry, but no (commercial), it's also far too complex for simple use. For simple Lab-Applications I'd use a "graphical coding environment" whic...

As with the graphics library, ... There you already have it: it isn't like the graphics library . (which is in FB for a long time) AFAIK: to trigger gfx-lib loading, there are only two KeyWords: Screen/ScreenRes Instead of defining umpteen new KeyWords (to load a new lib/feature) a single #Include ...

... it's very unlikely that your program will contain keywords named SOUND, PLAY, SineWave and so on, ... That is the point where you are wrong, I've at least one program that contains a procedure named SineWave() , but for drawing it, nothing to do with sound. Just assuming things is likel...