You may either want to use the circular buffer for holding the pointers of the actual strings or, more likely, for holding the strings themselves.
In the first case coding is pretty straightforward (you may use Wikipedia's circular buffe[^]r page for inception).
On the other hand, the second case is bit more complex, since you have to explicitely manage blocks of bytes (the strings) in the circular buffer.
THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?!
-- C++ FQA Lite
This is a good question because I'm not sure any of those really describes Windows messaging well. Sort of interesting given that it's the primary means of communication in the Windows desktop environment. I guess the rational behind this is that you can't really pass along data across messages, you can pass commands/messages and references.
I used to use messages a lot within an application to communicate but it's a bit different when dealing internal to an application because you can pass data by reference easily. Externally, you can only do that if the data is in a place that is accessible to both applications or meets certain restrictions (as described here[^]).
I am wondering if it's possible to create a DataTable object in one button handling event, and use it in another button handling event without getting error C2065: 'Datatable object' : undeclared identifier
As a solution of last resort i've made an attempt (see below) which is unsuccessful.
You should declare the object in your Form class and initialise it in the constructor or FormLoad event. It is then available to every other event handler or method within that class, whether public or private. This is basic C++ and nothing specific to CLI or Form apps.
My first suggestion would be: "don't write compound statements like that". As you can see they are almost impossible to figure out when they go wrong. Use interim values so you can check each stage of the code, like:
string dataReturn = dbdataset->Columns["DataReturn"]; // assuming this item is a string valuedouble doubleValue = System::Convert::ToDouble(dataReturn); // convert to double, but check for errorsdouble squareRoot = sqrt(doubleValue);
lblvol->Text = Convert::ToString(squareRoot);
Easier and clearer, and simple to step through with the debugger when errors occur.
Thanks for the advice. I will try it and let you know. Any idea why string type does not work from my side as opposed to your post? I am currently going it to see if people have encountered a similar issue.
might be a missing #include... as something is not logic here. as a matter of fact while typing any type double, float, char they are highlighted in blue therefore you could define any variable anywhere in the code based on those type.
however while typing string, the latter does not seem to be recognized at all (not even highlighted). string is considered as plain text and thus unrecognized
double, float, char are basic types which are part of the language, while string does not exist, but String (with capital S) is a class. If I spelt it with a lower case s before, then I apologise, as that is C# rather than C++.
The string class is an instantiation of the basic_string class template that uses char (i.e., bytes) as its character type, with its default char_traits and allocator types (see basic_string for more info on the template).
I will therefore work on your previous post and revert back to you tomorrow. Cheers