API trouble with Visual C++ .NET

About five months ago I tried using the XEM with Visual Basic 6. I was able to get it up and running but ran into problems with inconsistent data reads. Testing of the problem seemed to pointto the fact that data was being lost in the transfers. A co-worker, who is in Germany, is using the XEM with Visual C++ version 6. He reports having no problems with the XEM. So based on this I decided to move to C++. My problem is that I have very minimal experience with C++. I purchased a book and the corresponding software for Visual Studio .NET 2003 with Visual C++.

My understanding, through reading OK documentation and the forums, is that the DLL and corresponding files were written in Visual Studio .NET and that the people at Opal Kelly have not yet moved to version 2005. So it appears we are working from the same design environment. I have been able, to a limited degree, to communicate with an XEM board if I write a console program. I am still having problems with the pll portion, but I can write to a WireIn and make the LEDs toggle. Better than nothing so far.

I have been unable to make the software work with a windows program. When I start a new project I go under Visual C++ Projects and select Windows Forms Application (.NET). The code below is generated for the project. I put some controls on the form that I would eventually like to use to test various functionality of the XEM. I have tried putting #include “okFontPanelDLL.h” in various places and get all kinds of errors depending on the location of the statement. The design environment either does not recognize the #include or it does not recognize the class objects for the XEM at compile time.

Does the FrontPanel API work with a Windows Forms Application? If so, where do I put the #include statement? How exactly do I link okFrontPanel.dll to the project? Does anyone have a short example using the API with a Windows Forms Application?

Sorry if these questions seems simple or stupid, but I have become overwhelmed trying to figure this out by myself.

//******************************************************************
// Form1.cpp
//******************************************************************

#include “stdafx.h”
#include “Form1.h”
#include

using namespace XEMWindowsFormApplication;

int APIENTRY _tWinMain(HINSTANCE hInstance,
HINSTANCE hPrevInstance,
LPTSTR lpCmdLine,
int nCmdShow)
{
System::Threading::thread::CurrentThread->ApartmentState = System::Threading::ApartmentState::STA;
Application::Run(new Form1());
return 0;
}

//******************************************************************
// Form1.h
//******************************************************************

#pragma once

namespace XEMWindowsFormApplication
{
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;

///  
/// Summary for Form1
///
/// WARNING: If you change the name of this class, you will need to change the 
///          'Resource File Name' property for the managed resource compiler tool 
///          associated with all .resx files this class depends on.  Otherwise,
///          the designers will not be able to interact properly with localized
///          resources associated with this form.
/// 
public __gc class Form1 : public System::Windows::Forms::Form
{	
public:
	Form1(void)
	{
		InitializeComponent();
	}

protected:
	void Dispose(Boolean disposing)
	{
		if (disposing && components)
		{
			components->Dispose();
		}
		__super::Dispose(disposing);
	}

private: System::Windows::Forms::Button * cmdConfigFPGA;
private: System::Windows::Forms::Button * cmdWireIn;
private: System::Windows::Forms::Button * cmdWireOut;
private: System::Windows::Forms::Button * cmdTriggerIn;
private: System::Windows::Forms::Button * cmdTriggerOut;
private: System::Windows::Forms::Button * cmdSetPLL;
private: System::Windows::Forms::Button * cmdSetCLK;
private: System::Windows::Forms::Button * cmdPipeOut;
private: System::Windows::Forms::ProgressBar * progressBar1;
private: System::Windows::Forms::TextBox * txtWireIn;
private: System::Windows::Forms::TextBox * txtTriggerIn;
private: System::Windows::Forms::TextBox * txtP;
private: System::Windows::Forms::TextBox * txtQ;
private: System::Windows::Forms::TextBox * txtDiv;
private: System::Windows::Forms::TextBox * txtF;
private: System::Windows::Forms::TextBox * txtConfigFPGA;

private:
	/// 
	/// Required designer variable.
	/// 
	System::ComponentModel::Container * components;

	/// 
	/// Required method for Designer support - do not modify
	/// the contents of this method with the code editor.
	/// 
	void InitializeComponent(void)
	{

// I deleted all this code because it was generated by the software and // dealt only with controls I placed on the forms.

	}

System::Void Form1_Load(System::Object * sender, System::EventArgs * e)
{
MessageBox::Show(S"Hello");

  }

};
}

Hello snedeker–

Have you been able to build any of the sample apps we include? DEStester is a good start because it is console-based. The version shipping with FrontPanel-3 uses the DLL. In fact, everything in FrontPanel-3 is DLL-based now because using static libraries is difficult with various compiler versions and makers.

Our GUI applications use wxWidgets because we wanted a consistent API that could build on our three platforms. Building with native GUI tools would be three times the number of applications we needed to maintain.

I’m not familiar with Windows Forms, but DLLs are a fundamental component to all platforms and languages. You should be able to consult the MSDN database to learn how to load and run methods from a DLL.

It may have been that you just misspoke, but you do not “link” with a DLL at compile time. You load the DLL at runtime and call functions that then pass your arguments to the routines in the DLL. These functions are called “stub functions” and we have provided them all in C and C++ for you. You need to compile these functions into your application. (okFrontPanelDLL.cpp)

In other languages, you generally need to provide these stub functions yourself.

Does this shed any light on the situation?

(by the way, your questions are more aligned with accessing a DLL from your application. You may be more successful if you Google for information regarding generic DLLs – not just ours. You’ll get a lot more hits if you leave any “FrontPanel” qualifiers out of your search. :slight_smile: )

I created a console project using the files under Samples\DES\Cxx. The program compiled and ran, but I get the following output:

---- Opal Kelly ---- FPGA-DES Application v1.0 ----
FrontPanel DLL loaded. Built: Feb 1 2007 08:50:03
Found a device: XEM3010
Device firmware version: 1.2
Device serial number: loUBlTBdvc
Device ID: Opal Kelly XEM3010
FrontPanel support is not enabled.

The last line concerns me. Also, I used to have firmware version 1.4 and thought I might need an upgrade, so I found a firmware file that came with the setup and now I am at version 1.2. FrontPanel support was not enabled in either version.

First, the firmware version is displayed when you perform an upgrade. So when you applied the firmware update, it would have said “1.2” as the version number.

FrontPanel support is referring to the FPGA configuration file. The FPGA configuration file you setup must support the firmware version you’re using.

If you’re on firmware 1.4 or earlier (for an XEM3010), you will need to use a config file that was built with the FrontPanel-1 HDL modules.

If you’re on firmware 3.0, you will need to use a config file that was built with FrontPanel-3 HDL modules.