Unicode Programming Help Visual C and Objective C :)

In the C++ version:
Just make a habit of using the T_CHAR type. If the build-mode is set to 'Unicode' then T_CHAR will resolve to a 16bit sized character, if not it will just resolve to a regular 'char'.
Also use functions such as '_tcscmp' instead of 'strcmp' as it uses the same compile-time macro trick. (Please login to see this link.)

In Objective-C:
The CFile class handles everything automatically concerning unicode and strings. Just just it's "readAString" functions (and similar). It knows the unicode setting already.
Behind the scenes the iOS runtime is fully unicode

AFAIK making properties in EDIF is exactly the same as making them with the official SDK.

Check out the example properties in my fork of EDIF:
Please login to see this link.
It is true that it is the same as in rSDK, but that doesn't mean you already know how to do it. Hopefully one day I will get around to writing the Please login to see this link. article on it.

You don't determine if the user is using unicode; you tell MMF2 whether a particular version of your MFX file is meant for Unicode; you can use the macros defined by the build configurations (just check if _UNICODE is defined).

As for saving/loading properties, that has to do with the editdata - that gets complicated, but I've tried to simplify it in my fork of EDIF. Basically you have to store everything in a serialized state as though it were in a file.

I just look at some code for detecting it and I got the following (this is for an extension that looks at internal structures and so must know if it is unicode version or not at runtime):

#define EF_ISUNICODE 113 // Returns TRUE if the editor or runtime is in Unicode mode
#define EF_GETAPPCODEPAGE 115 // Returns the code page of the application
__inline BOOL mvIsUnicodeVersion(LPMV mV) \
{ return mV->mvCallFunction(NULL, EF_ISUNICODE, (LPARAM)0, (LPARAM)0, (LPARAM)0); }
__inline int mvGetAppCodePage(LPMV mV, LPVOID pApp) \
{ return mV->mvCallFunction(NULL, EF_GETAPPCODEPAGE, (LPARAM)pApp, (LPARAM)0, (LPARAM)0); }

void toMultiByte( LPRDATA rdPtr, const char* source , int nchars, char* dest ) {

LPMV pMV = rdPtr->rHo.hoAdRunHeader->rh4.rh4Mv;
if ( mvIsUnicodeVersion(pMV) )
{
LPCWSTR pNameW = (LPCWSTR)source;
WideCharToMultiByte(mvGetAppCodePage(pMV,rdPtr->rHo.hoAdRunHeader->rhApp), 0, pNameW, nchars, dest, nchars+1, NULL, NULL);
}
else
strncpy(dest,(char *)source,nchars);
}

// etc...

I thought the whole purpose of building separate versions or the MFX for Unicode and Non-Unicode was so that you could use #ifdef _UNICODE, not to mention it changes the parameter lists for some functions.

Indeed, but you'll at least want to verify that your choice is correct. The above code was useful for me because I did not create unicode and non-unicode versions (as it was only for interacting with internal MMF structures. It would be silly to create a whole new version for such a minor change)

Ah, jax - I had not realized your project was set up that way. The EDIF SDK has separate build modes for each of Nromal, Unicode, and HWA.

EDIF also has Runtime.IsUnicode() and Runtime.IsHWA() which basically check the values in the MMF2 structs, which is why I criticized your lengthy solution.

Which SDK are you using?

In your EDITDATA structure, you ar storing pointers. These pointers will be written to a file (the MFA, the EXE, etc.) and the memory they pointed to will be long gone. You have to actually store the data in the structure, not just point to it.

You can either have a fixed-length character array (which I suggest not doing), or you can ask MMF2 to dynamically resize the editdata to suit the length of the data you need to store in it (which there is an example of in SetpropValue).

In my fork of EDIF, I've streamlined the process and made it much easier to deal with:
Please login to see this link.
Please login to see this link.
The commented out examples show you what you have to do to properly set it up. Like I said, it's like writing to a memory mapped file.

This really needs to be dealt with in MMF3. The current way is ridiculous by today's standards - if we could just read/write to editdata in a stream fashion it would be so much sweeter (of course someone could write a wrapper for the current one, but meh!)...

Quote from Looki

This really needs to be dealt with in MMF3. The current way is ridiculous by today's standards - if we could just read/write to editdata in a stream fashion it would be so much sweeter (of course someone could write a wrapper for the current one, but meh!)...

I've been planning on doing that with EDIF, but I haven't had time. It's definitely on my list of things to do, though - I've already researched how to implement a C++ stream, now I just need to figure out how to make it interact with the MMF2 SDK.

Quote from Crazy_Ivan

LB I'm using EDIF.
Would it be easier if you could make a simple dummy extension (preferably in EDIF ) that demonstrates using properties, serializing them, deserializing them, etc because I can't get it to work no matter how much I try

Did you look at those links I posted at all? All you have to do is remove the comments and you have a working example.

Quote from Crazy_Ivan

And while I agree completely with you Looki, I honestly think someone should just make a nicer SDK with those features (maybe released with MMF3 that supports compiling for MMF2 -> 3?). Just ideas though as I would have no idea how to create a nicer SDK

EDIF is a nicer SDK, and I'm continually making it nicer

Haha, I think automatic is pushing it quite a bit too far - not even Java's serialization can do that very well. I will be making it easier soon, though.

The EDIF global files are all mostly the same (except for some bug fixes), but the template project has had an extreme makeover. The Please login to see this link. is updated for the changes in my fork. I'm still going, too - trying to make extension development even easier and more fun by abstracting things even more.