I linked only part of the /lib folder , my mistake.
Still like to know if my original question - linking to network resource is feasible.
This is basically result of my inability to ".configure" for non - native architecture.
The "configure" kept asking for dependency after dependency.
So I ended up running .configure on required architecture.
After a detour I am back to tying to implement / crosscompile C++ code.
I can option a prefix for desired architecture , but still having an issue linking to specific desired architecture libraries.
I was unable to use ".configure " to create correct foreign architecture library on "local" architecture.
I did a hack by copying an entire "foreign" folder to local device and was partially successful linking to it.
Still missing some library and could do same hack.
Is there a more "elegant" way to accomplish that?
Here is what is still failing to link correctly.
Sorry for the mess.
System.Windows.Markup.XamlParseException: ''The invocation of the constructor on type 'CommonXFS.Interface.Utility.MainWindow' that matches the specified binding constraints threw an exception.' Line number '5' and line position '9'.'
FileNotFoundException: Could not load file or assembly 'Interop.NXCameraXLib.1.0, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
IS there a way to return from DoModal without having a PUSH BUTTON with the value of IDOK ,IDCACEL or IDABORT I would like to have 3 radio buttons specifying 3 choice and return the value of one of those to DoModal
Is there a way to return from DoModal without having a PUSH BUTTON with the value of IDOK?
You would need to call the EndDialog function with the second argument set to the ID of your radio button. If you are not using Windows API and are using MFC instead... you would call CDialog::EndDialog
My DoModal is being called from
My CMainFrame once returning to DoModal via EndDialog the Dialog box is destroyed but the class/object is still around ( I created the modal Dialog on the stack ) so the data in the class is still available until I exit the CMainFrame Routine
Also the only way to have a bad return code from UpdateData is to call pDx->fail which has the side effect of an exception which I would have to delete. if everything is okay I just call EnDialog notifying the CMainFrame which called DoModal of my selection
Also the only way to have a bad return code from UpdateData is to call pDx->fail which has the side effect of an exception which I would have to delete. if everything is okay I just call EndDialog notifying the CMainFrame which called DoModal of my selection
OK, let me know if you have any problems here. But from what you've described it sounds like the desired outcome.
only one Issue UpdateData seems to always return TRUE
That means UpdateData() succeeded. Can you explain to me why you need UpdateData to fail?
even if I call pDX->fail
With my experience I am going to make a strong inference that your pDX variable is a pointer to a CDataExchange object. Can you explain to me why you need this to fail? If this fails a runtime error will be thrown... I can't even think of a valid reason you would want this.
The source for UpdateData() is inside wincore.cpp and you will find that the UpdateData() function constructs a new CDataExchange object and attaches it to your Cwnd object and performs DDX through there.
In other words... your line of code inside your class:
pDX->Fail(); // This fails because it's a pointer to another CDataExchange object.
You should to open [Your Visual Studio Path]\VC\atlmfc\src\mfc\wincore.cpp and scroll down to the Updatedata() implementation where you will immediately understand why UpdateData() always returns TRUE; It creates a new CDataExchange object inside the function. You cannot force UpdateData() to fail by manipulating an external object.
I've been meaning to tell you that I am happy to see you have finally moved over here from CodeGuru. I followed Chris over to his new site some 18+ years ago soon after Zafir Anjum sold codeguru and I rarely go back to the old site anymore.
Victor Nijegorodov wrote:
Why do you need the UpdateData at all? There was a great essay about Avoid UpdateData of Joe Newcomer. I'd recommend you to check it out!
Actually in this case he may need to call UpdateData() because he is bypassing both the CWnd::OnOk and also exiting the dialog with EndDialog(SOME_RADIO_ID); With that knowledge go and read the final two paragraphs in the debate between Doug Harrison and Dr. Newcomer.
If we are going to suggest that the poster "ForNow" avoid using UpdateData() then we need to ensure that he is using control variables.
I haven't used MFC in nearly 10 years, not sure why I even remember these things.
I'm trying to re-create the client part of the improved example but it's not working. When I tried to do some debugging I was looking at some values and I've found this:
Looking for some explanation I made some research and I understood that -among other things- this might be happening because of some uninitialized pointers, but I tried that suggestion and still no luck with MSVS 2008 and this simple code for a client-server application.
//-----------//// Client//-----------//void main()
//Once the CoCreateInstance is called, the component
//will be created and the client can not
//control it, that's why CoCreateInstance is inflexible
//and the solution is to call CoGetClassObject function
hr = ::CoCreateInstance(CLSID_Component,NULL,
pIComponent->Print("COM from scratch.");
*///-------------------------------//// improvement of the client code//------------------------------//// By calling the CoGetClassObject function, the client can control// creation of the component
pIComponent->Print("COM from scratch.");
What could be the reason(s) this
variable is returning that value and how to fix it? Thank you in advance
Perhaps there is something useful in this[^] thread.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
I saw that discussion and I see all those errors are related to a poor server registration. In my case, I double checked that my server is registered when I was doing some debugging. If you see the paths provided in the sources there is certainly something like this:
All my entries are OK with my server registered so I suppose the problem is somewhere but I can't find it because my lack of expertise. Looking at the MSDN/documentation the value expected should be one of these:
Location and connection to the specified class object was successful.
The CLSID is not properly registered. This error can also indicate that the value you specified in dwClsContext is notin the registry.
Either the object pointed to by ppv does not support the interface identified by riid, or the QueryInterface operation on the class object returned E_NOINTERFACE.
There was an error reading the registration database.
Either the in-process DLL or handler DLL was not found (depending on the context).
The executable (.exe) was not found (CLSCTX_LOCAL_SERVER only).
There was a general access failure on load.
There is an error in the executable image.
The executable was launched, but it did notregister the class object (and it may have shut down).
and not that negative value
What could be happening with this variable
if all variables/pointers are initialized and the server/COM Object is well registered with its CLSID for a Win32 app target?
Yes, I have registered the server. First, I did it with the script provided by the tutorial (you may take a look at my previous messages), then I made a double check manually comparing the registry entries and it was running perfectly. I'm using for this project MSVS 2008 to avoid problems because the tutorial is very old (2004) and everything is kind of mandatory with the Win32 target (no x64 builds). I'm confused, if not registered (but it is), I should get the something like this
//The CLSID is not properly registered. This error can also indicate that the value you specified in dwClsContext is not in the registry.
I don't know how to fix it, but you can find ot more about the error code by converting it to hex (e. g. with the Windows calculator:
-2147221164 corresponds to 0x80040154
Then go to this page[^] to find this code and look up its meaning:
This error code is listed as REGDB_E_CLASSNOTREG, which means "Class not registered."
P.S.: Only now I see that this is what you've been discussing with Victor above. Sometimes I'm blind....
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Hello Stefan, thank you very much for your inputs. By the way, I've been out of town this weekend, I apologize for not being around on time in my own discussion. Many thanks to Richard McCutchan and jschell as well.
Stefan, all that makes sense. This error (or status) code is trown at the
function. As I'm following the tutorial instructions, and even the original sources to be sure I'm learning step by step, my guess is that there is something missing with the registration required and those what you can find in the typical .reg file provided. Yes, it's a 15 years old (really good) tutorial and maybe Windows 10 doesn't get along with all those old keys and need something else (I don't know, just guessing, he he). I'm going to make a more in deep research about this because, clearly, the COM Object needs more "registration" somewhere.
Last Visit: 31-Dec-99 18:00 Last Update: 9-May-21 22:34