|
It's still hard? For 2 days? You should really do something to remedy this. Go grab some tissues, lock yourself into a quiet room and go nuts. Afterwards it will be much easier to concentrate on the programming problem and solve it in no time!
|
|
|
|
|
plz send me codez, sir. 
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello
I have a problem and will be very appreciated if somebody can help me with it.
We have software which run 3rd party tools and read response from StdOut.
How this implemented:
Main software create 2 pipes
Then create process for 3rd party tool and assign these pipes
Then read all data what send to StdOut of created process
And that very good works on Win95-WinXP.
But not under Vista.
Under Vista I cannot read any data from *.com files (old DOS format files).
Anybody know what can be reason?
Does Vista have some restriction for this files?
Any security issues?
Under WinXP any problem, all works very good with *.com and *.exe.
Also when I run in command line:
C:\Temp\>cc51.com > res.txt
res.txt is empty.
(cc51.com is the tool what we run in created process).
Any help will be appreciated.
Igor
|
|
|
|
|
|
Thank you for answer.
I read these articles, but this is not my case.
I have 32 bit Vista and I can run this application and they work well.
The only issue - I cannot get output.
Any other ideas?
|
|
|
|
|
Slepchenkov wrote: I have 32 bit Vista and I can run this application and they work well.
Did you mean that the .com application is working well in Vista ? Could you please explain how you made that conclusion ? 
Could you please share what happened when you type
C:\Temp\>cc51.com and the message/output you seen at your console ?
|
|
|
|
|
Please see screen shot with command window:
www.bipom.com/support/cc51shot.png
As you see i started new command line in Windows Vista and run cc51.com.
It runs and return usage info.
Any other messages/warnings.
So it works.
This is compiler for C programs. I also can compile files under Vista with it.
So it works well.
Please note, I have Vista 32bit, not 64bit.
|
|
|
|
|
Since I don't have a copy of cc51.com, I couldn't do any more tests to find out your problem  Sorry.
But from the sample screen and your original post, I have a question,
Are you missing something ?
The usage of CC51.com shows that you have to give the <name> right ? And the options too...
is it like C:\Temp>CC51.com some_file.c -q > res.txt
|
|
|
|
|
I simple use cc51 without parameters to show that it works.
Thank you for help.
|
|
|
|
|
Hello friend,
I have created DLL for the device using serial comport.
After sending the command, I am receiving ANSI characters raw data from device as below:
e.g 1>
0x00 0x08 0x1b 0x1a 0x10 0x00 0x02 0x00 0x00 .......
e.g. 2>
0x10 0x3c 0x0F 0x00 0x08 .......
I want to store this data in MS ACCESS (.mdb) file.
Problem :
1> Whenever trying to store the data, it stores into the database data
up to NUL(0x00) character.
2> Not able to store NUL(0x00) and data content after NUL character in database.
Please give me any suggestions for storing the data in database.
Thank you
|
|
|
|
|
Member 4620216 wrote: Please give me any suggestions for storing the data in database.
Have you tried using an "OLE Object" field rather than a "Text" field?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Thanks for the reply.
But OLE object will just embed or link any file .doc or .jpg with the excel.
I want to store special charcters in the database.
Is there any way other than it.
|
|
|
|
|
Member 4620216 wrote: But OLE object will just embed or link any file .doc or .jpg...
...or other binary data.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
About special character conversion,
Try encoding the characters, you may get some idea from here[^] and here[^]
Member 4620216 wrote: 0x10 0x3c 0x0F 0x00 0x08 .......
I want to store this data in MS ACCESS (.mdb) file.
To store binary data as such in MS ACCESS, use BLOB data type. See this [^]for details.
|
|
|
|
|
Hi,
The below code works fine in VC6.
double i =-3.3;
double j =2.4;
double result = pow(i,j);
if (result <1.0E-13)
{
printf("true");
}
else
{
printf("false");
}
In VC6, IF condition is true. Whereas in VC8, its failing.
Could any one explain the reason, why its failing in VC8.
Thanks,
Anandi
|
|
|
|
|
dotnetkoders wrote: In VC6, IF condition is true. Whereas in VC8, its failing.
Have you looked at the actual value in both? In VS6, the value of result is -1.#IND000, indicating NaN for floating-point numbers.
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
Yes. In VC6, result value is -1.#IND000000000 whereas in VC8 -1.#IND000000000000
|
|
|
|
|
So rather than call pow() with invalid input, why not check the base value first, or call _isnan() on the result?
"Old age is like a bank account. You withdraw later in life what you have deposited along the way." - Unknown
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
|
|
|
|
|
dotnetkoders wrote: Could any one explain the reason, why its failing in VC8.
Because VC8 is compliant with IEEE754[^], whereas VC6 wasn't (did VC6 comply with any standards, I wonder, 'cause it didn't comply with the C++ standard either. Anyway.)
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
What is your definition of 'works fine'?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hello,
I have a C++/MFC application, which can be extended by its users by means of a PlugIn interface. This interface uses simple dll mechanisms (no COM). Now I want to add a functionality to allow these PlugIns to be written in .NET languages. Therefore I created a wrapper PlugIn, which sits between the MFC application and the .NET user PlugIn. This works very well so far. However, I have one problem. Some PlugIns might require to extend the user interface of the MFC app by controls in order to apply specific settings. The method for this, which is to be implemented in the native dlls, has the following prototype:
HWND CreateSettingsWindow(HWND wndParent);
Where wndParent is the window handle of the parent window on which the control should be placed.
What I do in the wrapper is create a .NET form control from this handle and pass it to the wrapped .NET PlugIn like this.
HWND CreateSettingsWindow(HWND wndParent)
{
System::Windows::Forms::Control^ ctrl = System::Windows::Forms::Control::FromHandle((System::IntPtr)wndParent);
System::Windows::Forms::Control^ ctrlSettings = (*this->m_pWrappedPlugIn)->CreateSettingsWindow(ctrl);
if (ctrlSettings != nullptr)
{
return (HWND)ctrlSettings->Handle.ToPointer();
}
else
{
return NULL;
}
}
The wrapped .NET PlugIn now creates its control (derived from System.Windows.Forms.UserControl) and attaches it to the controls collection of the parent window:
public override System.Windows.Forms.Control CreateSettingsWindow(System.Windows.Forms.Control parent)
{
MySettingsControl ctrl = new MySettingsControl();
parent.Controls.Add(ctrl);
return ctrl;
}
The control is created correctly and as it seems I can even access it from the MFC application (at least I can read its size). But it will not show up on the parent window. Regardless what I do (visible property, show method, ...) it will not become visible.
Any idea what could be wrong with my approach or what might be missing would be very helpful.
Thank you very much
|
|
|
|
|
Did you make the HWND you originally created visible as well as the .NET part of the deal?
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Yes, I did.
I found the problem. Obviously System::Windows::Forms::Control::FromHandle fails for window handles, which were created by Win32/MFC and not with .NET. Thinking about it, this makes sense.
Luckily I found a nice tutorial on the web, which pointed me into the right direction:
http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.languages.vc/2005-07/msg00752.html
So I moved the code, which attaches to control to the parent window, from the .NET to the native code section.
The .NET control creation changed simply to the following:
public override System.Windows.Forms.Control CreateSettingsWindow()
{
return new MySettingsControl();
}
And the attachment to the parent uses the good old Win32 function SetParent:
HWND CreateSettingsWindow(HWND wndParent)
{
System::Windows::Forms::Control^ ctrlSettings = (*this->m_pWrappedPlugIn)->CreateSettingsWindow();
if (ctrlSettings != nullptr)
{
::SetParent((HWND)ctrlSettings->Handle.ToPointer(), wndParent);
return (HWND)ctrlSettings->Handle.ToPointer();
}
else
{
return NULL;
}
}
Might it be worthwhile to publish an article about this here on codeproject?
Thanks
|
|
|
|
|
rwe1812 wrote: Might it be worthwhile to publish an article about this here on codeproject?
Definitely - it sounds like something that a) could trip up other people, and b) isn't documented as clearly as it could be.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Hi,
I am opening an application through another application using CreateProcess().
If the exe is running already I am sending a message through PostMessage otherwise I am opening run the exe and send message.
I found the running instance using FindWindow(). But some times FindWindow() is returning " NON-NULL" although app is not running.
I am confused with this behavior.
My Window Caption is "DDKK";
And My code to FindWindow() is:
HWND hWindow=NULL;
hWindow=::FindWindow(NULL,_T("DDKK"));
if(hWindow==NULL)
{
STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
CreateProcess (CSanProApp::GetAppPath(0) + _T("abc.exe"),
_T(" und"),NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
Sleep(4000);
}
::PostMessage(hWindow,Opendialog,0,0);
Please suggest me any solution, why the FindWindow() is returning NON-NULL value although window is not running.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
