|
Colours in windows are either set in the class (default background) or painted in the OnPaint() event, so your code needs to handle it. I don't think there is anything in the Registry that could help.
|
|
|
|
|
|
|
Hi,
I made one combobox which i canwrite some text, in C# and i build that as DLL.
And i call this to VC++.
My problem, when it is in C#,i can write text in combobox.
But in VC++,i cannot write.
When i press alphapets in keyboard nothing is displayed in combobox. only beep sound is coming.
Whats the mistake?
Anu
|
|
|
|
|
Anu_Bala wrote: Whats the mistake?
Given the information you have provided it could be anything at all. Perhaps there is something wrong in your code.
|
|
|
|
|
this i coded in C#
private void Callbutton_Click(object sender, RoutedEventArgs e)
{
String msg = comboBox1.Text;
comboBox1.Items.Add(msg);
CallClick(msg);
}
And im using this in VC++ and im using that 'msg' in vc++ code.
Anu
|
|
|
|
|
I am still none the wiser as to what you are doing. The above code is for a private C# event handler, called when some button is pressed. How does this relate to C++ and what exactly do you mean by the statement:
Anu_Bala wrote: And im using this in VC++ and im using that 'msg' in vc++ code.
|
|
|
|
|
Yes i created on C# dll with this coding and im using that in VC++.
public partial class SecondTab : UserControl
{
public delegate void NameTab(string msg);
public static event NameTab CallClick;
public SecondTab()
{
InitializeComponent();
}
private void Callbutton_Click(object sender, RoutedEventArgs e)
{
String msg = comboBox1.Text;
comboBox1.Items.Add(msg);
CallClick(msg);
}
}
This is my C# coding.
Im using in VC++ as follow
Tabcontrol::SecondTab::CallClick += gcnew Tabcontrol::SecondTab::NameTab(OnCallClick);
static void OnCallClick(System::String ^ msg)
{
CString m = msg;
}
I think now you understand my objective..
Anu
|
|
|
|
|
Anu_Bala wrote: I think now you understand my objective.
I understand that in the C++ function OnCallClick() you create a CString copy of the message from the ComboBox. Beyond that I have no idea what you are trying to achieve or what your problem is.
Your original post stated that you could not enter values into the ComboBox.
|
|
|
|
|
Yes,
I cannot enter any values in that combo box.
Just i tested this WPF C# dll with one WPF applcaiton.
In that its perfectly working and i can enter values.
But here i canot.I thought the combox is not working,so i add simple text box and test it with VC++.Again i cannot enter any value in textbox.
If i copy some text and paste there.Its get pasted.And CString perfectly return that value.
Anu
|
|
|
|
|
Sorry, but I have no idea why or how you cannot enter data from the keyboard and yet you can enter via copy and paste. As this is Managed C++ rather than ordinary I cannot offer any further suggestions, other than using the debugger and trying to figure out what is happening in the library at the time the Combo has the focus.
|
|
|
|
|
Anu_Bala wrote: I made one combobox which i canwrite some text, in C#
Anu_Bala wrote: Whats the mistake?
Yes, that's it. 
You measure democracy by the freedom it gives its dissidents, not the freedom it gives its assimilated conformists.
|
|
|
|
|
Is there a way to declare a dynamic array in such a way so that it can't be deleted ?
What I'm actually trying to do is control access rights to an array returned by a function. I've basically managed to do what I meant but permission is still granted to deallocate memory for it, not that I/someone would do that because allocating memory for it is not allowed but it just seems improper for that access right to be granted when only the class it is a member of should be allowed to delete it.
The following code :
const int* const pMem = new int[5];
delete [] pMem;
is legal. Where as :
pMem = new int[5];
is not legal after declaration of pMem.
I don't imagine somebody would try to delete a const array but still, they can, so how can deletion be prevented ?
many thanks.
modified on Friday, January 1, 2010 7:10 PM
|
|
|
|
|
Instead of returning a pointer to a fundamental data type like int you could return a pointer to a custom class, let's say Integer, which has the delete and delete[] operators overloaded.
This way when the user tries to delete the returned pointer, your class method will be called in which you can decide to either delete memory or throw an exception or assert it or simply ignore it.
|
|
|
|
|
that's a good idea.
but unfortunately, I don't think it would be suitable for the case I have.
I've implemented a container class so the array at hand is an array of user defined types.
It would be ok if I could make a template subclass of user class, which was an exact copy and where the delete / operator delete was definately not overloaded by the user's class but so the container is more all round, I'll leave it how it is.
I think there's probably no reason for someone to delete the array when they can see it's declared const. So maybe the best solution is to just add a comment so a user knows not to delete it directly. Or an example of how to use the container.
Now, I have a better idea of what's possible and what's not.
thanks
|
|
|
|
|
doug25 wrote: Is there a way to declare a dynamic array in such a way so that it can't be deleted ?
Sounds like a common API problem, I could imagine three solution. Maybe use a data buffer class that can handle memory allocation/deallocation of its elements, something like std::vector with restrictions. Alternatively use a smart pointer template with shared ownership, something like boost::shared_ptr where the instance will be automatically destroyed when the last copy of the shared pointer is destroyed or gets out of scope. Alternatively, even if you didn't ask for it, let the caller provide a memory buffer and be responsible for the memory allocation/deallocation.
Hope it helps,
M
|
|
|
|
|
Hi,
thanks for the suggestions.
I've actually decided not to change what i've done so i'm not seeking further help but I'll try to explain the situation better so you understand the conclusion I've come to since it's a bit more complicated than it may seem.
I'm sure the implementation of the container is ok and user friendly. The only issue is that memory for a member array shouldn't be deallocated by a user despite them having the permission. Although this shouldn't be a problem because someone probably wouldn't assume they should deallocate memory via a const pointer that's a member of a container class (correct me if i'm wrong) and anyone who's used a map or vector container should know it's not up to them to manage the memory for a map or vector's member variables. The container I've implemented is a specialised map and like a map it manages it's own memory. Since the array is declared protected I'm sure users would have the sense to check whether it's safe to manually deallocate the memory it uses and the function to retrieve the array has a const specifier in it's declaration which means memory can't be allocated for it, which should indicate to users that they shouldn't delete the array themselves I'm assuming.
What would totally solve the issue is if the C++ language (or compilers) made it so a dynamic array declared const couldn't be deleted. I don't see why it's possible to deallocate memory pointed to by a const dynamic array variable using delete while it's not possible to allocate memory for it using new. Ah because the address of a const pointer can't change but memory for a given address can be deallocated.
Basically the container I've made is a map that stores elements in a contigious array where it's possible to specify the order that they are stored in. I say array but it's actually a block of memory allocated with operator new and never new [] or new. The memory is always freed with operator delete. The reason for managing memory allocation for the "array" this way is so the calling of elements constructors / destructors is more controlled i.e. constructor is not called when inserting element, it's only called when inserting a new element and destructors are not called when the array is resized which makes it a very useful kind of container.
A vector wouldn't work because being able to retrieve a dynamic array manipulated by the container is a key reason why this container would be useful compared to standard ones. When I want to store elements mapped to keys and pass a customly ordered array of the elements to some other function that requires an array of maybe void* this container will be extremely useful. I don't want to go into too much detail but that's why I've implemented the container to use an array and not vector. A vector will call destructors of elements when it is resized and that's quite undesirable in certain cases.
If I understand correctly boost::shared_ptr wouldn't work because to access the array the way I need / intend would require dereferencing the pointer to it which would mean the variable retrieved would be in the same condition as what is returned by the Array() function at the moment. But I'm not sure what you meant by using a shared_ptr ?
Using a buffer passed by the user wouldn't be a practical solution because of the way memory is managed using operator new and operator delete by the container. For the container to work properly, it would basically require that the user never allocates memory for the buffer because the container also associates indices with keys so things would get a bit complicated. The user would have to only ever call operator delete on the buffer and let the container do the rest.
So my conclusion is that bearing with the mild (I think) issue that the array returned by Array() can be deleted is probably the most simple solution. The user only needs to know not to delete it, and i'm sure most users would assume that.
|
|
|
|
|
Hi! I tried to understand the problem you describe, this came in mind... probably it's the same as my first post but a little bit more detailed.
1) use data containers (STL or your own implementation) when ever possible, avoid manual memory allocations with new and delete.
2) alternatively rely on RAII (Resource Acquisition Is Initialization) that memory is automatically deallocated when an object goes out of scope (smart pointers from Boost or your own implementation). Such a smart pointer is responsible for encapsulating dynamically allocated memory and knows itself when to deallocate the memory again. You can even prevent application code from deleting a pointer that is being managed with a shared pointer, super fancy. 
This is how I avoid situations where a developer wonders "do I own that pointer? do I need to delete it?". With the options shown above it is easier to keep control of ownership and lifetime in my opinion. I rarely call new and delete in application code. When designing APIs I often use a buffer/container object that a method can fill up or the class has methods/accessors to retrieve individual information. All of the above can be enforced with a C++ coding standard[^]. I suggest to have a look at Boost's shared pointer techniques[^] and maybe generally think about memory handling strategies from a overall design point of view.
Hope it helps.
/M
|
|
|
|
|
thanks
that was helpful.
i'll check out boost and STL. The container I've made is quite specialized though and works for the poject I'm doing, so I might stick with it but if there's a better way I'll try and find that before continuing with the project I'm doing.
|
|
|
|
|
I forgot STL meant standard template library.
I had a look at some implementations of smart pointers and found some of the techniques interesting but tending on ugly then I thought of a pretty ideal simple solution to the problem. This class will work to allow elements in a dynamic array to be modified while preventing the user from allocating / deallocating memory for the array itself :
template<class TKey, class TValue>
class SpecialMap
{
public:
template<class TKey, class TValue>
class InternalArray
{
protected:
friend SpecialMap<TKey, TValue>;
TValue* pElements;
public:
TValue & operator[](UINT nIndex)const {return pElements[nIndex];}
};
So a user knows they shouldn't manage the memory for the array.
And it's still possible to use the array in functions requiring a void* as I mentioned for example by using &internalArray[0].
For what my program's supposed to do I think it would be a great deal more convenient using my custom container than standard ones but I will try to stick to the standards when possible.
|
|
|
|
|
What you say about smart pointers looking ugly. Absolutely true, template code is not easy to read and looks complicated at first because it is more abstract, on the other side using it is very very easy. Once you get used to the (object oriented) idea of memory being handled by smart containers/pointers, you don't miss old-school manual memory allocation. After all it is 2010 now! 
From looking at your code... why don't you use a class inherited from std::vector<TValue> and make some methods you don't want to expose (e.g. resize and clear) protected?
/M
|
|
|
|
|
I was going to have a look at the boost shared / smart pointers that have definately been well implememented but I downloaded boost and my computer started playing up, well the file menu in the boost zip folder stopped working, and it was fine in other zip folders. No virus's detected. So I'll stay away from smart pointers at the moment cause I don't need them (although technically maybe the InternalArray class is a kind of smart pointer cause it is used like a pointer and means delete can't be called on it).
I don't want to use a vector because with full optimizations vector lookups are about 8200 times slower than dynamic arrays meaning you could do 8200 * 1000000 accesses to elements using a dynamic array in the time it takes to do 1000000 using a vector, which should make a fair difference in the program i'm writing and it's not only the resize and clear functions that call element destructors, even inserting an element will call destructors for all the other elements in the vector, or at least the ones that change position in the internal array. I don't see why a standard container would be implemented so destructors of elements are called when the array is resized, but of course I know why it works like that just not why someone decided to implement a vector / map etc. like that.
well, I'm happy with the code I've written
thanks for the advice / suggestions
|
|
|
|
|
Actually, I was wrong about optimisation being a problem, the vector's only slower when using the overloaded subscript operator to access elements but it's possible to make a pointer to the vector's internal array by getting the address of the first element so elements can be accessed using the pointer when faster accesses are needed. But this would mean a pointer would have to be made that holds the address which could be a bit crude to program.
|
|
|
|
|
doug25 wrote: I don't want to use a vector because with full optimizations vector lookups are about 8200 times slower than dynamic arrays
Strange, I can not confirm this behaviour in my software. I don't know what you mean by "lookups", but basic read/write access with vectors should be really fast. Here is a pseudo code to read a file into memory:
CFileStream file;
if(file.Open(sFileName, CFileStream::STREAM_READ))
{
std::vector<unsigned char> buffer;
buffer.reserve(file.GetSize());
file.Read(&buffer[0], file.GetSize());
}
doug25 wrote: even inserting an element will call destructors for all the other elements in the vector
This is by design. Vectors use a single continuous block of memory, so when you insert one element a couple of elements need to be relocated to make space in the middle. If you take for example a vector<unsigned char> this gives you pretty much the same memory access as using a block of dynamically allocated bytes. There are other STL containers with different memory layouts and runtime behaviours (lists, maps, etc).
So long,
M
|
|
|
|
|
By "lookups" I just meant accessing an element by using the subscript operator e.g. vec[nIndex].
I took a more accurate reading. For accessing a million elements, using a dynamic array e.g. value = pArray[i] is 8455 times faster (on my pc) than using the overloaded subscript operator on a vector e.g. value = vec[i] where ints are used as elements.
I'm sorted though cause I've made my own array handling functions, so I can safely use arrays. The functions make use of operator new, operator delete and placement new when required and this means I have control over how constructors / destructors are called when I need to resize array's etc.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
(