Member Avatar

Hello, and greetings to those I may be speaking with in this thread over time. I present to you a problem, rather fringed and minimal and troublesome.

First, I'll start by saying that I don't really consider myself a programmer so much as I do an enthusiast who now, suddenly, employed to learn and write in C++ for software development.

Unfortunately the majority of what I'll be talking about here is heavily limited in disclosure so, for that I apologize.

Onward to the problem;

I'm working in the development of an addition to Autodesk MotionBuilder for use at the office. We're writing the entire item in C++ using the OpenRealitySDK includes and libraries. The snag I've encountered is an inability to update a textfield (FBEdit) with live data. In this case, the position of an object in the scene. Just as well, we're working without a debug console which is resulting in a lot of blind guesses between the compile and the crash.

Primarily my question would be;
Could a log file be employed to monitor variables, software problems, memory leaks (this is the most likely one I believe). Where we could essentially watch MotionBuilder in its dying moments to create a reasonable notion of what's happening.

A modified example of the code presently is:

void ORDeviceInputLayout::InterfaceEventListener (HISender pSender, HKEvent pEvent){
FBEventInput MyEvent(pEvent);
MyTextField.Enabled = true;
MyTextField.Text = FBEventInput(pEvent).X.AsString();
MyTextField.Enabled = false;
MyTextField.Text = "INNACTIVE";

That's the bulk of it, where MyTextField is the textfield in question already added to the interface and MyEventTrigger represents the checkbox to enable and disable the event.

I know it's a stretch that people here may even know the ORSDK but I could use any help or suggestions you may have, even if it's a finger pointing to a logfile tutorial.

I won't stop learning.

Documentation for the OpenRealitySDK for MotionBuilder 2012 is available here.

Well, if you can't run it in the debugger, then add some print statements to the code to help isolate where your are crashing. BTW, where are the variables MyTextField and MyEventTrigger declared and instantiated? Please show. Also, do indent your code so it is easier to read.

Member Avatar

My explanation or understanding may be lacking, but I'll try.

I'm new to C++; not as new as to say I don't know why hashtags are before includes and defines. But new enough to say I'm not entirely comfortable with deference and pointers and new enough to be very out of the water when writing a DLL for software I've never used through an SDK I've never touched.

What comes from this is that I'm not in my element here, but the process is as follows to the best of my understanding.
Code >> Compiled >> MyAddon.DLL >> Open MotionBuilder >> Load DLL >> Test UI >> Crash.

Compiling as release. Because we do not have the funds to 'participate' in the Autodesk Development Network and so we don't have the debugging client of Motionbuilder.

I suspect my best opportunity is to be able to writeup something of a crash log however I've not really any experience with file streams in C++ so writing out, particularly during running the software is uncertain.

I suppose if anyone may have a greater resource than just a "plug and play script for MFC" that could work, since it seems a lot of the write out attempts I've made from the code are not compiling despite appropriate includes, and when they do, I'm getting no response that I can find.

The text area and trigger are being iterated in the UICreation section which is a class in and of itself, it works as an event call and is currently locked in a separate file as it's not the segment I am working on; presently I'm working on event callbacks and in this case, the response is not exhibiting the way I seem to think it should. What I don't know is if it's my source or MotionBuilder that's the problem and if anyone has experience with the SDK then that would be most beneficial, otherwise I'll retract my request for help.

Sorry to have inconvenienced anyone.

Even if you don't have the Autodesk debugging tools, you should be able to use Visual Studio's debugger in order to look at the call stack, variable values, and such.