|
thanks Richard with some fiddling got it working!
pretty stoked, the possibilities are now endless 
|
|
|
|
|
Hi,Im using WPF as C# dll in VC++.Im sending datas to the Listbox inthe third tabitem in a tabcontrol by using this coding.
void CToolTab::SendPresetmenu(CString menu)
{
FrameworkElement^ page;
String ^ msg = gcnew String( menu );
Globals1::gwpreset->AddPresetmenu(msg);
page = Globals1::gwpreset;
Globals1::gHwndSource->RootVisual = page;
}
By this code,wat happend is my entire tabcontrol becomes a third tab item.there is not other tabs .
If i commented those last two bolded line.Full tabcotrol appears correctly but the listbox doesnot contain text.
How can i do that?Anu
|
|
|
|
|
I created a c++ .net dll, in which I need to implement logging. I decided to go with Microsoft Enterprise Library's Logging.
Now, I am calling this dll from a COM application (I created a .tlb from the dll to use in the COM application), and the error I am getting is this:
Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
How can I get around this??
TIA
|
|
|
|
|
chana gibber wrote: Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=3.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
That is pretty straightforward. Is that file exist?Best wishes,
Navaneeth
|
|
|
|
|
yes, the file exists in the debug folder of my (c++) dll.
It did not get carried over to the debug folder of the COM exe.
What do I need to do with Microsoft's dll in order to get it running in my exe?
|
|
|
|
|
| Have you tried copying it manually to the COM exe's folder? If it didn't worked, use dependency walker and profile the EXE to identify which dependency is actually failing. Best wishes,
Navaneeth
|
|
|
|
|
yes, I tried copying it. But remember, this is a COM exe. Does that require a tlb file instead of a dll file?
|
|
|
|
|
I got it working. I created a tlb file for each of Microsoft's dlls using regasm/tlb
|
|
|
|
|
Wow I am burning my brain right here... I'm so very close to just saying screw it and writing some sort of conversion myself.
First I'd love to know if there is an existing macro to do what I want to do...
I have a char array:
char OutputBuffer[1024] = {0}; (huge i know, but ill lower the size later  )
that has a byte put into it... (78 AB 45 44) is a value I had at one time... as a float it means 790.67919921875
note!: this value has been read straight from memory
The problem is I cant get this DWORD into a float for the life of me...
Is there any existing macro? If not throw me a bone and tell me how i might convert this into a float from scratch...
|
|
|
|
|
Mattzimmerer wrote: The problem is I cant get this DWORD into a float for the life of me...
If this is already a float (as you state) then there is nothing to do. If you mean reference it as a float then you just use the (float) cast in front of the reference.
Or do I misunderstand your problem?MVP 2010 - are they mad?
|
|
|
|
|
I don't know about an existing macro, but this will do it:
char OutputBuffer[4] = { 0x78, 0xAB, 0x45, 0x44 };
float d = *((float*)&OutputBuffer[0]);
|
|
|
|
|
This worked great, thanks!
Now i have a new trick lool, why didnt i think of that: cast it as a pointer of the type i know it is and then deference it =D...
|
|
|
|
|
Assuming your code is managed and you're in the right forum, have a look at BitConverter.ToSingle()
 Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. [The QA section does it automatically now, I hope we soon get it on regular forums as well]
|
|
|
|
|
One caveat to the BitConverter class is the endianness it uses is based on the architecture of the machine the program is running on. So if you're interfacing to a piece of hardware and its endianness doesn't match the endian-ness of the computer, or you're reading a binary file created on a computer with a different endianness and using BitConverter, then BitConverter will not give the correct result.
DybsThe shout of progress is not "Eureka!" it's "Strange... that's not what i expected". - peterchen
|
|
|
|
|
Sure, whatever method is used, one better is aware of all applying conventions; endianness being the most relevant one here.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read code that is properly formatted, adding PRE tags is the easiest way to obtain that. All Toronto weekends should be extremely wet until we get it automated in regular forums, not just QA.
|
|
|
|
|
The CLSCompliant attribute does not work in C++/CLI. You can see my report on this some time ago at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=431084&wa=wsignin1.0[^] and Microsoft's refusal to fix this.
Is there any other way to check for CLS compliance in C++/CLI code ?
I have tried to use FxCop but there is no subset of FxCop rules which I have ever found which checks only for CLS compliance. I have no interest in trying to either spend days figuring out which subset of FxCop rules is CLS compliant or of trying to change my code to satisfy all of FxCop, many of whose rules I find way too finicky for my own .Net programming practice.
Hopefully there is some way to check for CLS compliance in C++/CLI now that Microsoft refuses to support this for C++/CLI programmers.Edward Diener
|
|
|
|
|
Edward Diener wrote: Hopefully there is some way to check for CLS compliance in C++/CLI now that Microsoft refuses to support this for C++/CLI programmers.
I am not sure about alternative methods to enforce this. And AFAIK, MS is not supporting C++/CLI much. 
Following is my explanation about why compiler can't enforce this,
As Jonathan Caves said, C++'s compilation model is making this difficult to implement. Each source file will be compiled into object files independently and it is hard for the compiler to check for the attribute defined in another translation unit. If you apply this attribute for the assembly, then it will be in AssemblyInfo.obj file. Compiler cares only about the current translation unit and don't know anything about other translation units. This makes it hard to find the attribute usage which is on another translation unit.
Best wishes,
Navaneeth
|
|
|
|
|
I do not believe that the C++ compilation model is any different from the C# compilation model in respect to checking for CLS-compliance. This is because CLS-compliance only refers to public CLR types and a CLR class's public/protected methods, properties, and events, not to the actual code being written. In this sense I do not see why CLS-compliance could not be enforced in C++/CLI.
I do realize that C++/CLI allows for non-CLR types to be mixed with CLR types. But if CLS-compliance is truly only about checking CLR types, then I really do not see what is the big deal for enforcing CLS-compliance in C++/CLI since what needs to be done is a matter of the C++/CLI compiler checking only the CLR types and not the actual code, which may be mixed mode C++/CLI programming.
Is not the C++/CLI compiler already able to distinguish what is a CLR type from a native C++ type in C++/CLI ? Obviously it can, in which case just checking that the signatures of those types are CLS-compliant should not be hard for the C++/CLI compiler.
It is just sheer laziness on the part of the C++/CLI programmers at Microsoft which keeps them from supporting the CLS-compliant attribute in C++/CLI. And of course without that support is is nearly impossible for C++/CLI to create CLR assemblies which are guaranteed to be CLS-compliant and therefore will be interoperable with other CLR languages.
I already know that Microsoft's support for C++/CLI is subpar. See my post at http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/bfe69a25-8973-4d41-8064-a7153dc1580b[^] for my own opinion. But if C++/CLI programmers simply acquiesce to Microsoft's nonsense about why they can not do anything about it, such as the reply I got to my bug report regarding CLS-compliance, it can not get any better.Edward Diener
|
|
|
|
|
Hi,
I am calling a C# function CreateService() from C++/CLI, but It is taking as CreateServiceW() and showing compile error, method not found. So I am unable to compile. Anybody knowing why it is behaving like that.
regards,
Charan.
|
|
|
|
|
Member 4386569 wrote: I am calling a C# function CreateService() from C++/CLI, but It is taking as CreateServiceW()
This is the Unicode version of the function, which the compiler automatically calls if your project is compiling for Unicode rather than ASCII.
MVP 2010 - are they mad?
|
|
|
|
|
Yeah, I am compiling for Unicode, Thanks for your reply. I write the following preprocessor directive.
#ifdef UNICODE
#define CreateServiceW CreateService
Now it is successfully compiled.
regards,
Charan.
|
|
|
|
|
Also be aware that if it is not Unicode, the name will become CreateServiceA.
MVP 2010 - are they mad?
|
|
|
|
|
In the MSDN article on "C++ Stack Semantics for Reference Types" it says that:
"A compiler-generated assignment operator will follow the usual standard C++ rules with the following additions:
*
Any non-static data members whose type is a handle to a reference type will be shallow copied (treated like a non-static data member whose type is a pointer).
*
Any non-static data member whose type is a value type will be shallow copied.
*
Any non-static data member whose type is an instance of a reference type will invoke a call to the reference type’s copy-constructor."
Regarding the last item:
1) First it implies that a CLR reference type can be a non-static data member of a native C++ class since, unless I am mistaken, a compiler-generated assignment operator never occurs for CLR classes. Yet elsewhere I also read that a native C++ class having a member that is a ref class type is ill-formed.
2) Secondly, given that 1) is allowable I would have intuited that the assignment operator for the instance of the reference type would calll the user-defined assignment operator for the reference type and not the user-defined copy constructor for the reference type.
It seems I am misreading badly something in this topic, even though I understand what C++ stack semantics for reference types are about, or else the explanation above is badly mangled. I hope somebody can straighten me out on the wording above.
Edward Diener
|
|
|
|
|
|
| The topic just finishes saying that the compiler will not generate a default copy constructor or assignment operator for a reference type and then it starts in on what I quoted in my OP. That entire section seems out of place in the topic and I have never been able to understand what it means, whether it is referring to a an assignment operator or, as you suppose, a copy constructor. If it is referring to a native C++ class, as I suppose, I was under the strong impression that a native C++ class can not have a data member which is an instance of a CLR class so I can not understand what it means. Edward Diener
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
