|
|
|
Hi I cannot compile the following code
The error is
1>.\STL_CLR.cpp(3) : fatal error C1083: Cannot open include file: 'cliext/vector': No such file or directory
Here is my code
Person.h
#pragma once
using namespace System;
ref class Person
{
public:
Person() : firstName(" "), secondName(" ") {}
Person(String ^first, String^ second) : firstName(first), secondName(second) { }
~Person() { }
virtual String^ ToString() override
{
return firstName + L" " + secondName;
}
private:
String^ firstName;
String^ secondName;
};
STL_CLR.cpp
#include "Person.h"
#include "stdafx.h"
#include
using namespace System;
using namespace cliext;
int main(array<string> ^args)
{
vector<person^>^ people = gcnew vector<person^>();
String^ first;
String^ second;
Person^ person;
while (true)
{
Console::WriteLine(L"Enter a first name or press Enter to end: ");
first = Console::ReadLine();
if (first->Length == 0)
break;
Console::WriteLine(L"Enter a second name: ");
second = Console::ReadLine();
person = gcnew Person(first->Trim(), second->Trim());
people->push_back(person);
}
Console::WriteLine(L"\nThe persons in the vector are:");
for each(Person^ person in people)
Console::WriteLine("{0}", person);
return 0;
}
</string>
|
|
|
|
|
I've been tryin to debug this switch statement but i get error after error. The code is suppose to allow the user to enter a value between 1 and 3. and then some please help with this code:
#include <iostream>
using namespace std;
int main()
{
int num;
cout << " Enter an integer number: 0-3" << ;
cin >> num;
switch (num);
{
case 1:
if (num==0)
cout << ; "You Entered: " <<num << ;
break;
case 2:
cout << "You Entered: " << num <<;
break;
case 3:
cout << "You Entered: " << num = num * 2 <<;
break;
default;
cout << "Invalid Input" << endl;
}
return 0;
}
|
|
|
|
|
The code has lots of errors.
Ending lines with << won't work.
Extra semi-colons all over the place where they don't belong.
Clean those up and you have something like this:
int num;
cout << " Enter an integer number: 0-3";
cin >> num;
switch (num)
{
case 1:
if (num==0)
cout << "You Entered: " <<num;
break;
case 2:
cout << "You Entered: " << num;
break;
case 3:
cout << "You Entered: " << (num = num * 2);
break;
default:
cout << "Invalid Input" << endl;
}
That should compile.
As for the runtime logic - You check if num==0 under case 1...
num will ALWAYS be 1 if it gets there - why check if it's 0?
You ask the user to enter number 0-3, yet 0 is an invalid number.
If the user enters 3, you tell the user 6 was entered.
Also, this code has nothing to do with C++/CLI so you've posted on the wrong board.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
What is the equivalent of a window in .NET? Is it a form? I don't mean the visible UI window, but the window handle used as a message pump.
Consider the following situation - Application A loads DLL B (on its one and only thread). DLL B spawns a new thread to receive data, but has to send that data to application A on the same thread as it was loaded. The usual practice (at least I think so), is to have a hidden window within DLL B, created on the application's thread, and the data-receiving thread posts a windows message and the received data to that window handle. The window procedure then sends the data to application A.
If you were to implement this in C++/CLI, what would you use instead of the hidden window?
Here's the real problem I'm facing: we have such a system as above, originally developed as a MFC application and native C++ DLL. It works perfectly in this case. However, the application had to be converted to a windows service written in C#. In this case, PostMessage within the DLL stops working. Using it as a native C++ DLL or compiling with /clr makes no difference. The PostMessage function itself succeeds, but the message disappears into nowhere. Any idea what could be happening here? Would the solution be to replace the window with a form (using BeginInvoke)? So far, MSDN and Google have got me nowhere...
The real system is actually much more complicated than I've described, I've just tried to separate the problem area here.
Thanks in advance!
Last modified: 31hrs 59mins after originally posted --
|
|
|
|
|
A window should still work in the service - it just won't be visible
to any logged on user (not that it was anyway). You should be able to debug
and check if the window was created successfully (is its HWND valid?).
It's certainly not necessary to post messages to a window for interthread
communication, and in a performance situation could be less than ideal.
I would use callbacks and/or regular function calls and proper thread synchronization.
There's no reason for a UI thread unless you have a UI.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark, thanks for the reply!
Yes, I checked everything possible. As I said, PostMessage itself succeeds, its just the message that dissapears. In fact, the very same code works when called from a regular application.
You are right about not needing to post messages for interthread communication. It was just that all this was pre-existing code that we were hoping to reuse without a major rewrite, but it looks like I'll have to look into some other method after all...
|
|
|
|
|
We figured out the origin of the problem, here's the solution posted for anyone interested.
In hindsight, it was quite obvious really. The hidden window in question was created in a DLL loaded directly from the service's OnStart method. If it was loaded from a UI, the message loop would operate as expected and posted messaged be delivered, but in the service's thread, the message loop does not operate.
The brute-force solution is to spawn a thread from OnStart and load the DLL there. The thread then creates a window and waits in its message loop (until the service is terminated). Any windows created within the DLL then work as expected.
(looks like a subtle bug[^] to me... )
|
|
|
|
|
If you are running under Vista or Server2008, the service is in window station0, but the logged on user is in window station 1+. In Xp and otherearlier OS's this only happeded inf terminal Services was installe. You could count on the first logon using station 0, so windows messages could be used to communicate with the service. This will not work with Vista or Windows Servier 2008 and later OS.
See This blog article[^] and the white paper it links to for more detailed information.
Note that if your dll is running in the process of the service itself, window messaging will still work (Intra process communication), but if it is running in a client application in a user login (inter process communication), it will not, since the main session message pump is different - session 0 programs will never see session 1 windows messages and vice -versa.
|
|
|
|
|
I have database with many records I want to display each record by click its button, on the same textbox so how could I bind one textbox with many records and each record has own button.
|
|
|
|
|
Work with CurrencyManager[^] class. Set the Position property to change the current position.
|
|
|
|
|
Hi guys,
What is the most common methodology to do a self integrity check on your program and quit in case of any kind of modification (like cracking attempts)?
I did some research and CRC seems to be a good way but there are arguments about CRC vs MD5. Implementing md5 for self check is not possibe only if you use a preloader which extracts and checks the main program. You can't tell the md5 before you would compile your program.
I looking for a solution which can be implemented into my program not a 3rd party exe protector (which is the easy way to do this).
|
|
|
|
|
Since you're asking on a managed-code board...
There's some built-in stuff already available to you:
Assembly Security Considerations[^]
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi all,
I have a problem with dialogs...
After using ShowDialog() method to show a dialog, memory usage (in Task manager) rises
Up about 3 Mega bytes. But after closing that dialog only 1 mega byte of memory releases.
I don't know how to free the extra memory that a dialog makes after closing it!
please help me...
Thank you.
Every new thing you learn,Gives you a new personality.
|
|
|
|
|
Call Dispose method of the form. Or just use using block and it will be automatically called for you.
|
|
|
|
|
Giorgi's reply is correct, but since this is a C++ board, I'll
assume you're using C++/CLI...
You should call Dispose on IDisposable-derived objects. More
important than releasing memory is releasing unmanaged resources
held by the object.
In C++/CLI, these are the ways to get Dispose() called on an object
(taken right from the docs):
*If an object created using stack semantics goes out of scope. For more information, see C++ Stack Semantics for Reference Types.
*If an exception is thrown during the object's construction.
*If the object is a member in an object whose destructor is running.
*If you call the delete Operator (C++) on a handle (^ (Handle to Object on Managed Heap)).
*If you explicitly call the destructor.
Using delete is the most natural C++ way IMO...Here's an example:
Form ^frm = gcnew Form();
...
delete frm;
You're still not going to see all memory released using task manager.
There will still be many managed objects that will be released when the
GC gets around to it.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Adding to other replies
You can use Stack Semantics to automatically delete object when the scope ends. So don't use handle when creating object. Write like this
Form2 frm;
frm.ShowDialog(); When variable goes out of scope, it's distructor will get called automatically.
|
|
|
|
|
What everyone else said, plus:
dSolariuM wrote: After using ShowDialog() method to show a dialog, memory usage (in Task manager) rises
Up about 3 Mega bytes. But after closing that dialog only 1 mega byte of memory releases.
What is going on in that dialog? If code in the dialog is allocating memory or resources then you are responsible for cleaning it up. Simply closing the dialog will NOT free any memory or resources that your code specifically allocates, including the dialog object itself if you allocated it on the heap.
led mike
|
|
|
|
|
Hi everybody.
I am currently working on a tool which is using satellite assemblies (.resx) string tables to support localisation.
Additionally, i would like to change the Culture manually by choice.
While changing the current language inside the program is working fine when started in Visual Studio (2008),however, it doesn't work in the release (tested on a vmware machine).
Well here is an example code, maybe someone can give me an hint why it works in Vs and not outside.
private: System::Void pictureBox1_Click(System::Object^ sender, System::EventArgs^ e) {
String ^loc;
loc = "de-DE";
wechsleSprache(loc);
}
private: System::Void wechsleSprache(String^ loc) {
Thread::CurrentThread->CurrentUICulture = gcnew System::Globalization::CultureInfo(loc, false);
Thread::CurrentThread->CurrentCulture = Thread::CurrentThread->CurrentUICulture;
this->Controls->Clear();
InitializeComponent();
this->textboxCurrentUICulture->Text = System::Globalization::CultureInfo::CurrentUICulture->Name; }
cheers,
joerg
|
|
|
|
|
jreisslein wrote: it doesn't work ... maybe someone can give me an hint
Hint? Good idea, maybe you can give us a hint about what "it doesn't work" means?
led mike
|
|
|
|
|
it doesn't work means:
when running inside VS, the program changes the language when clicking on the pictureBox. However it won't do when trying on a compiled version.
hope you understand now
|
|
|
|
|
if anyone is interested, i found the reason for this behaviour.
the local translation are all placed in satellite assemblies (.resx) files, and in a compiled version they are expected to be in subfolders of the working directory.
e.g. the translations for the de-DE Culture should be in ./de-DE/<assembly.dll>
Somehow the Setup Routine didnt include those assemblies and therefore the program could not find em and did fall back to its default language.
cheers
|
|
|
|
|
So it had nothing to do with C++/CLI. Glad you got it working and thanks for posting back the outcome.
led mike
|
|
|
|
|
Hi All,
I encoutered an issue in my program that uses .net serial port component. The scenario is as below:
1. I have developed my program and it works fine in "debug mode".
2. When I compile and run it in "Release mode", something wrong happened to the program. Some of my program logic
is no longer working as in "debug mode".
3. After performing some debug, I found out that the problem is I am using a while loop (pooling) on a flag
'AckReceived', and the flag is in an inconsistent state in 'release mode'.
Brief description on my serial port program design,
1. Main thread send a packet of serial data through serial port to external device, and expect an acknowledgement
within an interval, or else timeout will occur.
2. After sending data, main thread will perform a while loop to pool the 'AckReceived' flag. If it is true or
timeout occur, jump out from while loop.
3. When data is received at serial port, my receive event handler (port_DataReceived) will be fired to process the
serial data. The delegation is assigned as below:
objSerialPort->DataReceived+= gcnew SerialDataReceivedEventHandler(this,&CSerialPort_Driver::port_DataReceived);
4. When complete parsing the data, if a full serial packet is received and verified ok, 'ACKReceived' flag will be
set to true.
**Remark: Parsing and setting the flag 'AckReceived' is all done in the event handler port_DataReceived.
5. When 'AckReceived' flag is set to true, my main thread will jump out from while loop and continue the remaining
logic.
Problem:
1. In 'release mode', even though serial packet has been received successfully, and the 'AckReceived' flag is set
to true, the WHILE loop in main thread will NEVER jump out until timeout. This means, in main thread, it always
see the 'AckReceived' flag as false.
2. The logic works fine in 'DEBUG mode'.
3. My temporary solution is to put a System::Threading::Thread::Sleep(5) in the WHILE loop to keep the WHILE loop
checking at lower frequency, and this make the 'release mode' works!!
Obviously, the temporary solution is not a perfect one, but it does give some clue that timing is a problem in
'Debug' & 'Release' mode.
However, I couldn't figure out what is the exact problem and debugging in 'relese mode' is very hard and I am
helpless now. I am new in .NET development and not really sure on the threading model of .NET serial port, hence
not really sure if this issue is caused by syncronization problem of the 'AckReceived' flag?
Please can anyone explain to me what happen here and if possible share with me some possible solution?
Thanks in advance!
Development environment:
1. Language: Managed C++
2. IDE: Visual Studio.NET 2005
3. Serial port component: Version 2.0.0.0
Best Regards,
Winson My
|
|
|
|