|
IF you have Windows xp Pro then try:
start->run and enter gpedit.msc
Under Computer or User managent find "Administrive Template", then find "Windows Component". there you will find "Windows Update" Inside you will find a lot of options. Thease options are difrent in "Computer managent" and "User managent"
I don't know for home edition.
ps: I hope this works
|
|
|
|
|
Actually i have checked out gpedit setting also but still it fails to work on specified schedule is there any else settings.
Very much urgents
With Rgds
VC++
|
|
|
|
|
Did you try to use windows update, to update this updater. Without it you can't use windows updater to updato your windows
|
|
|
|
|
I have been having a long debate with the developers in my company about porting our MFC software to C++.Net. The main concern is performance really. The software's primary goal is to track the flight of a ball in three dimensions using vision processing techniques. The software is, however, notoriously unreliable, with pointer errors and other software problems causing crashes quite frequently. Many of you may find this laughable but we are still using the VC6 compiler in Visual Studio 6. Aside from that, having had brief interludes with the .Net framework *and* MFC, I feel the .Net framework is far easier to use than MFC and seems to be a lot more stable too. From what I've seen and heard, .Net seems to be the answer in terms of development and productivity.
The other developers argue that the main issue is real-time performance. They feel that trying to get as low-level as we are would be difficult in .Net (but it's not like we're coding in assembly or even C for that matter; just standard C++). I believe they simply have a misguided understanding of how it all works. They seem to believe that the CLR is functionally the same as the Java Virtual Machine and that the intermediate language requires an extra layer of processing. My understanding is that the main purpose of the MSIL is for cross-platform compatibility and that it is possible to compile to the native machine language thus resulting in performance comparable to a Win32 compiled version.
Firsty, is this the correct analysis, and secondly can anyone give me URL where I could find information on benchtests comparing MFC v .Net compiled C++ programs?
|
|
|
|
|
Klempie wrote:
MFC software to C++.Net
Sounds like hell.
Klempie wrote:
The software is, however, notoriously unreliable, with pointer errors and other software problems causing crashes quite frequently.
Not wanting to be rude, but .NET won't compensate for bad code.
Klempie wrote:
Many of you may find this laughable but we are still using the VC6 compiler in Visual Studio 6.
I wrote a lot of code in VC6, no crashes or memory leaks. The problem is not the compiler.
\
Klempie wrote:
I feel the .Net framework is far easier to use than MFC and seems to be a lot more stable too. From what I've seen and heard, .Net seems to be the answer in terms of development and productivity.
Managed C++ is a PITA, IMO. If your dev team is not smart enough to use pointers, they will find other ways to write bad code in MC++ or C# ( I'd recommend C# ), and the end code will be slower. But, it's not going to give the sort of errors you have now, that much is true. Or, it can be.
Klempie wrote:
The other developers argue that the main issue is real-time performance.
They are sort of right. Managed code is compiled the first time it is run, the difference could be less than you think.
Klempie wrote:
I believe they simply have a misguided understanding of how it all works.
No, they are right. But, you may be right in terms of the difference not being insurmountable.
Klempie wrote:
They seem to believe that the CLR is functionally the same as the Java Virtual Machine and that the intermediate language requires an extra layer of processing. My understanding is that the main purpose of the MSIL is for cross-platform compatibility and that it is possible to compile to the native machine language thus resulting in performance comparable to a Win32 compiled version.
They are right. You cannot compile a native machine language version. The .NET frame work does that for you, just like the Java VM does.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
I am afraid you are stuck here. You obviously don't have expertise to write solid C++ code (MFC is not unstable, your code is), and .NET is not suitable for the kind of processing you do.
I would try to re-write the software in a simpler but performant language, like C or (seriously) Fortran, even at the cost of lost productivity. Or, if you like living on the edge, you can try something like D which claims to have high performance but is easier than C++.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
Hi folks!
I'm struggling to find a reliable way to build an interface between an unmanaged C++ application and a managed C# remoting application.
I've got to build an interface dll that's capable of signalling events by calling callback methods in given feedback objects.
This callback has to be called from the same thread the interface dll is being loaded in.
Something like this:
class MyObj
{
public:
virtual void OnXChanged(int arg) = 0;
} as declaration for the callback function.
The C# server is signalling the corresponding event by calling an asynchronous event handler in a managed class in my mixed mode interface dll.
Something similar to this:
void InitManagedServerComm()
{
ManagedCallbackObj* managedCallbackHandler = new ManagedCallbackObj();
pRemotingServer->RegisterEventClient(managedCallbackHandler);
}where ManagedCallbackObj is implementing an interface consisting of callback functions the remoting server is able to signal events with:
__gc class ManagedCallbackObj : public IEventClient
{
public:
void OnEventX(System::Object *pObj, MyEventArgs* pArgs);
...
}So far, so good, the remoting server successfully calls my managed callbacks (i.e. runs through OnEventX()), but this managed event handler function gets called from a different thread, not the one the dll was loaded in, of course.
So I need a way to transfer the event from the managed event handler to an unmanaged method in a different threat that's calling the given callback.
If I was in a pure C# world I'd simply create a Control and call Invoke(), but how to do this between managed and unmanaged?
Any ideas how to accomplish this?
Really stumped,
mav
|
|
|
|
|
I am really havin trouble understanding your problem but I believe that I have an ideea for you. Can you please try to explain a little more in depth what you are trying to do?
Is it an unmanaged class that you need to be called into when an event occurs? or the other way around.. please be a bit more specific.
Mik
|
|
|
|
|
Thanks for your reply!
It's a bit complicated.
I have to handle objects implementing an unmanaged interface, let's call it IUnmanaged.
Part of this interface is a notification function, something like void OnPropertyChanged(PropertyType type), that has to be called when a property of the object changes.
The other methods of IUnmanaged have to communicate with a C# remoting server (let's call its interface IManagedServer) to perform their tasks.
In order to be able to access the managed server, I'll have to use managed code, so the result is a mixed mode dll.
This server defines an event (ManagedPropChanged) which in turn has to trigger OnPropertyChanged() for a certain IUnmanaged object.
Usually I'd just hook up the events and in the event handler OnManagedPropChanged() I'd call pMyUnmanagedObject->OnPropertyChanged(PropertyA).
The problem is that OnManagedPropChanged() is called by the .NET remoting infrastructure from a different thread than the one my IUnmanaged object was created in.
I have to call OnPropertyChanged() from the same thread the object was created in, that's part of the IUnmanaged specification.
One way I've come up with is to create an invisible window from the original thread and to PostMessage messages to this window from the OnManagedPropChanged handler, but I was wondering if there is a
better way.
Regards,
mav
-- modified at 13:51 Monday 10th October, 2005
P.S.: You'll see that I've modified the code structure a bit so that the problem gets clearer, but the basic problem is the same as the one in my first post... 
|
|
|
|
|
Hi friends,
I want to know how to perform windows update. how windows update configure.
give me a reply.
Regards
kedar
|
|
|
|
|
I presume you are using windows xp with default setting. Click Start and then klik "Help And Support"
Find windows update. It shoud be lower right side.
ps: this question shoud be under SysAdmin dorum not in MC++ forum
|
|
|
|
|
Hello,
I am trying to build an dll in .Net, using managed C++. But i need to use
another dll in my project. I have the xxx.dll file and xxx.lib file.
But i do not know how to set my project to link it to my project.
I know how to do that in Visual Studio 6.0 C++, in Project Settings--->Link,
add "/libpath:../../lib" under "Project Options" and add xxx.lib under
"Object/library modeules". But i do not know how to do this in .Net. I am a
newcomer in .Net
Thanks for your help!
vic
|
|
|
|
|
Use "Add reference" and chose your dll or your project.
If you have two projects in one solution you will see your project on the list
if not, then you have to browse
|
|
|
|
|
Dear Sir,
Thanks for your help.
The dll (let's call it xxx.dll) I am going to use is not built by my project AAA.
I have only one project AAA and it builds a new dll (let's call it yyy.dll), which uses the xxx.dll. The xxx.dll I am going to use is from a 3rd party.
When I tried to:
right lick "Reference" under my project AAA, select "Add Reference...",
then "Add References" window pop up. I clicked "Browse" on the right side of this window, and the "Select Component" window appears. In this window, I browsed and chose the xxx.dll (which is in the same place as xxx.lib), and clicked "Open". In the "Add Reference" window, lick "OK", I got a error message:
"Microsoft Development Environment"
"Add Reference: Error adding reference to the project."
Could you please tell me what the problem is and how to solve this?
Thank you very much for your help!
Vic
|
|
|
|
|
I don't uderstand what your problem really is. If you have a .lib file for the library that you want in your project you can just add it to the "Aditional Librarie" under the Include part of the Project Settings. You could do that, or user the #import "xxx.lib" in order to actually make the library *part* of your project.
|
|
|
|
|
Dear Mickanu,
Thank you very much for your help. The problem i met was solved. I can include the .h file and input the .lib file into the linker and my project can be compiled.
Thanks for your help.
vic
|
|
|
|
|
Hello,
I have a very difficult requirement to implement. I need to Base36 (0-9, A-Z) encode/decode a large number(up to 45 digits)string. For e.g. “7211750854866385693202841128538807157909”. I already have a routine that does this conversion but it doesn’t handle more than 64 bits(__int64). I have been thinking about this but have no clue so far L
Any tips/pointers?
Thanks!
|
|
|
|
|
You can use Struct
__gc struct encode
{
__int64 n1;
__int64 n2;
};
|
|
|
|
|
You can use an array of characer variables to store the large number.
|
|
|
|
|
I'm trying to interface a DLL parameter with .Net String variable.
How do I convert the .net String type to LPSTR used on DLL parameter ?
Like this:
LPSTR sUser = this->edtUser->ToString();
but this cause the following error :
error C2440: 'initializing' : cannot convert from 'System::String __gc *' to 'LPSTR'
Fernando Oliveira
|
|
|
|
|
|
Hi Folks!
For an interface to another application I had to develop a C++ dll implementing a given interface. For testing purposes I had a VB6 emulator to try out my dll.
Everything worked well, but now that the dll is loaded into the real program, a windows message I send to fire an event from a different thread gets lost (i.e. is not received by the window I send it to).
The dll is a mixed mode dll. I'm registering a managed event handler for an event of a managed remoting server and this event handler is called without problems.
In order to signal the event back to the host program I have to transfer it to the original thread the dll was loaded in.
In order to achieve this I create an MFC window in the original thread and send a registered windows message to this window from the event handler.
This does work flawlessly in the test program, but when the dll is loaded into the real host application, the window doesn't receive the message.
Has anyone experienced something similar or can give me any hints on why this could be?
Thanks in advance,
mav
|
|
|
|
|
Update:
I was told my dll seems to work when the host application is not being run in the debugger.
I've read Surviving the Release Version[^] and think it could be related to mixing debug and release MFC (since I've delivered my dll as release build), but I'm not sure.
Nevertheless, any help would be greatly appreciated...
mav
|
|
|
|
|
Hi everybody
How can an application interact to a Windows Services or transact with it?
Tanks for your help
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
