Unicode Programming Help Visual C and Objective C :)

Hey guys,
I'm trying to build my first Unicode compatible extension and was wondering if someone can help me :)
(hinting at Francois, Anders, Yves, and anyone else who can help ;) )

Is it possible for someone to provide sample source code on how to:

1. Create a property using EDIF (Visual C++ source code would be great)
2. Determine if the user is using the Unicode version, (Visual C++ code)
3. Do I need to handle the data differently if it is the unicode version (Visual C++), i.e. different variables types? (char* for non unicode, wchar_t* for unicode??)
4. Is ho->hoAdRunHeader->rhApp->bUnicode the correct statement in Objective C to use to check for unicode?
5. Read in the property in both Visual C++ and Objective C

Sorry if the list is extensive :P

Kind Regards
Tim

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. (http://msdn.microsoft.com/en-us/libr.../e0z9k731.aspx)

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

Thanks for the TCHAR tip Anders :)

Can I get any help at making a property with EDIF? :)
I've tried several times but failed :(

Regards
Tim

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:
https://github.com/LB--/windows-edif...Properties.cpp
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 Wiki 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.

@LB: Thank you, very useful because I hadn't ever successfully made a property before :)

I'm trying to save/load properties and I'm doing something really wrong

Code:

---

struct EDITDATA
{
    // Header - required
    extHeader        eHeader;

    // Object's data
    TCHAR *appID;
    TCHAR *appSig;
};

//--------------------------------

LPVOID WINAPI DLLExport GetPropValue(LPMV mV, LPEDATA edPtr, UINT nPropID)
{
#ifndef RUN_ONLY

    switch(nPropID)
    {
        case Prop::Version:
            return new CPropDataValue(__CURRENT_VERSION__);
        case Prop::AppID:
            return new CPropDataValue(edPtr->appID);
        case Prop::AppSig:
            return new CPropDataValue(edPtr->appSig);
    }
#endif // !defined(RUN_ONLY)
    return NULL;
}

void WINAPI DLLExport SetPropValue(LPMV mV, LPEDATA edPtr, UINT nPropID, LPVOID lParam)
{
#ifndef RUN_ONLY
    // Gets the pointer to the CPropValue structure
    CPropValue* pValue = (CPropValue*)lParam;

    switch (nPropID){
        case Prop::AppID:
            #ifdef _UNICODE
            edPtr->appID = ((CPropStringValue *)pValue)->m_pWStr;
            #else
            edPtr->appID = ((CPropStringValue *)pValue)->m_pStr;
            #endif
    }
#endif // !defined(RUN_ONLY)

---

LB (or anyone else), can you help point out where I've gone totally wrong? :)

I'm a keen learner but definitely still new to properties

Kind Regards
Tim

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:
https://github.com/LB--/windows-edif...e/EditData.hpp
https://github.com/LB--/windows-edif...Properties.cpp
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!)...

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

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 :P

Tim

Quote:

---

Originally Posted by 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:

---

Originally Posted by Crazy_Ivan

LB I'm using EDIF.
Would it be easier if you could make a simple dummy extension (preferably in EDIF :P ) 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:

---

Originally Posted by 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 :P

---

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

Sorry I didn't actually try the examples in your fork, I was at work when I posted that message, I will attempt to use them in the morning and post back (2:30am atm haha :P )
And I agree completely that EDIF is a nicer SDK :P but making it auto handle edit time properties (serializing etc...) would be amazing :D

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.

Wow I only just downloaded your updated EDIF, I must of had a really old version of EDIF as mine is nothing like your current one :P

The EDIF global files are all mostly the same (except for some bug fixes), but the template project has had an extreme makeover. The wiki 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.