When it comes to this board I hardly get an answer I understand, but a little while ago I learned to google the words I didn't understand to their responses and this led me to the answer as some subjects they mention encompass a lot of knowledge. It at least shows a willingness to understand the answers you are given.

Where I am at now I usually get a buzz word like "quaternion" or "SLERP". While the poster has the knowledge of the subject they hardly have the time to explain its every use and implementation. Without them showing me these words though i would spend days trying to find a solution to my poorly worded google search! Lol

That being said I have seen you progress on this project for a while and you definitely show an aptitude for learning. I have not really messed around with qt or controllers yet, as I continue to live a fantasy that I may one day be a game designer.

I thank you Lesshardtofind, when i started doing this type of automation, it was in dos batch files, Basic,console programs and parallel ports!! Windows seemed to make things more difficult once they blocked direct access to ports starting in i believe windows 2000/xp. Decided to but the vellman k8055 board as a usb interface, as it installs as a HID, and doesnt need any "special" software, or drivers. and in console still works for me almost like the parallel ports used to. BUT then i decided to use GUI and touchscreen to control 320 relays. Still have alot to learn of course, and jumping right into it (like i do most things!) i have already learned alot. And if i kep to just one dialog box, or just one script, still works. long way to go though!

ELYSIA, thank you, read up on RAII, and smart pointers, as well as a little on destructor. so far, not as helpful with my program that i can see so far. STILL tryng to really understand classes, as well as how it would help with sharing a function. Classes still a little confusing!

I think you have a tendency to take a huge project to solve a small problem. That backfires. If you encounter a problem, build the smallest compilable example and solve your problem there, then transfer your solution.

In this case, your problem is calling a function from one cpp file in another cpp file. No QT, no external dll, nothing. Just two cpp files. Make a new project, add 2 cpp files and solve your problem. Only when it's solved, transfer your solution back to your huge project.

Somebody already told you above but I will try to rephrase that:

main.cpp

Code:

int main()
{
}
int function(int x)
{
return x*2;
}

other.cpp

Code:

void other_function(int z)
{
return function(z) + 17;
}

This will not compile as you already found out. Because you are missing a prototype of "function" in other.cpp. To make sure this prototype is the same across all cpp files, we put those prototypes in extra files called headers.

function_header.h

Code:

int function(int x);

Now both files need to know that this header exists so you need to #include it. Add

Code:

#include "function_header.h"

to the top of your other.cpp file. Now it should compile.

hth
-nv

She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."

If I were you I would just spend more time on it. There is no rule that says you have to get something right away. I think it took me a week to get the right collision algorithm for walking on sloped surfaces.

I can say from my past that every program I wrote in c++ without classes was poorly written and poorly designed. The moment you understand classes your programs will immediately become more organized and hopefully more re-usable as well. As for function pointers I really have only used them when required by a windowing interface like GLUT.

I agree with nvgoit on the fact that you seem to be overcomplicating the solution. Sometimes it helps to take a step back from coding and researching and just sketch out a map of all your functions (and classes eventually) and how they interact with each other. In the long run thinking about everything and asking yourself questions like. "Do these really need to interact?". "Does x NEED to know about y?".

Is going to lead to better design, input to output flow, and less unforeseen bugs. Some things just have to be learned as you go, but I promise that when you "get" classes you will never look back.

and
l:\relaydlltest1\Functions.h:5: see declaration of 'OpenDevice'
going right to

Code:

intOpenDevice(intCardAddress);

i dont understand how i am "overcomplicating the solution", when i have yet to have a solution. i did exactly what both of you said. Make a header that declares the function, and then include it in both sources....

debug\dlltest2.exe:-1: error: LNK1169: one or more multiply defined symbols found

ALOT less errors, then again i am only trying to load/call one function from dll....

i know it is something simple i must be missing....

and hard to know what to change/edit as

1) using the supplied DLL to send to the PIC with custom boot
2) trying to edit there "demo" and "sample" code
3) have no idea how to work with multiple sources (like stated before i have always only used 1 source file)

i learned to program on my own, with help from others here and there when it came to something i never knew.
so i understand the "i am not doing it for you" which i love. but i do need more then just a "read the book" type answer as the "books" i have found, are no help with this!

a broke down simple example would be freaken great instead of 4 days of VERY general answers, even after stating i have no idea how to write headers, very vague idea of how to load a DLL (as i learned from 40 different pages, which all had something different) to be honest, i am getting sick of the "try this" with my reply of "nope", then "well you need to fix it" with my reply being "how" and the response "i already told you, with a header" it has become a 4 day never ending circle. Even when i teach in lab, when people have tried, i atleast break it down to simple terms that they (who have NEVER programmed before) can understand. Well with the DLL`s, Headers, Multiple sources, QT Creator, 4 things i have NEVER used untill about a week ago, i need a little more explination of what the hell i am doing....

and that was using the same headers that made the dll, so making a header for a dll so that i can use a function call no matter where i call it in the application is driving me nuts, i have rewrote this program about 15 different times, atleast 15 different ways, and end up with the same result, or worse.

Unfortunately, that is how many things are. There are really never clear answers. There are only bits and pieces. You have to puzzle them together. Yes, I know it is frustrating, but you have to get used it because this is not the last time you'll have to deal with it.
Anyway, some general pointers and what is going wrong.

In functions.h, you have:

t_func4 OpenDevice;

And this is your problem. You've declared a global variable, which is included in both .cpp files. This mean you have two variables with the same name that are globals. That is an error and that is why you get an error saying it is already defined.
The fix? The best fix is to avoid global variables altogether. Failing that, you need to define the variable in one and only one .cpp file. Then, in the header, declare it as

extern t_func4 OpenDevice;

This essentially tells the compiler that it should not define a variable (because of "extern"), but also at the same time tells the compiler that it exists, but in another source file. So, so long as you have defined it in one source file, it will not complain.
Now, some general pointers:

Code:

int init(void) // Using "void" when no arguments are needed is just an ugly relic from C. You can get rid of it.
{
hDLL = LoadLibrary((LPCWSTR)L"k8055d"); // Avoid global variables as much as possible. Don't cast strings.
if (hDLL != NULL) // This is an anti-pattern. Use if (!hDLL), then terminate.
{
OpenDevice = (t_func4) GetProcAddress(hDLL, "OpenDevice");
if (!OpenDevice) // Same here. Anti-pattern.
{ // handle the error
FreeLibrary(hDLL); // Cleanup should be done via RAII
return -2;
qDebug() << h; // This will never get executed.
}
return 0; // ok
}
return -1; // error load DLL
}

Crossfire, I can understand that this is quite frustrating. C++ isn't easy. But you need to start with the small (or not so small) basics like header files and classes. A project that dynamically loads a dll in a cross platform gui framework is way out of your league if classes and RAII aren't in your reach yet.

I'll take a wild guess and say that you have no idea what this line does:

And that's ok. It's freaky stuff. But you cannot base your program on something that you don't understand. That simply won't work.

For example, if I'm not mistaken, that line tells me that the library will be unloaded at the end of the init function when the shared_pointers destructor (after making sure it was the only reference) calls the lambda expression. So your global variable with the function pointer will propbably be invalid after init.

I will repeat my advice: divide and conquer. Your program fails and you don't know why. Make your problem set smaller. You tackled multiple cpp files and headers. Now forget about multiple files and your Gui framework. Can you write the smallest possible program dynamically loading your dll and calling a function? If you can, combine the solutions.

hth
-nv

She was so Blonde, she spent 20 minutes looking at the orange juice can because it said "Concentrate."