|
The *best* way is to integrate with sourcesafe or CVS. That way you get a code history as well as the ability to check out the bits you need. If you can't do that, then invest in a good differencing tool, and keep a master copy somewhere of the project, merging changes into it.
Christian
NO MATTER HOW MUCH BIG IS THE WORD SIZE ,THE DATA MUCT BE TRANSPORTED INTO THE CPU. - Vinod Sharma
|
|
|
|
|
I highly recommend a source control system, such as Visual SourceSafe. It's essential in team development.
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
Thanks, Visual SourceSafe does sound to be the best option. We both have Visual Studio.NET Enterprise Edition. Does anyone know if it is included in this already, if not, where can I get it from??
Thanks,
grahamoj.
|
|
|
|
|
According to this[^], it's already included.
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
I spawn a CDialog class dlg from my View class. In the DLg class I have a handler for postNcDestroy, which sends a message to the parent (the view)
m_pParentWnd->PostMessage(..); .
Now if this window is up (the dlg) and I go to exit the app, it crashes in the debug version of the exe, but does fine in the release. I sort of traced it to the fact that is debug asserts on IsWindow(m_hwnd) when I do the postmessage. I did:
In PostNcDestroy()
if (IsWindow(m_pParentWnd->GetSafeHwnd()))
{
m_pParentWnd->PostMessage(..);
}
and its okay but I feel nervous since I sort of tricked it. Why does it debug assert saying its not a window if I dont do my trick? I though the sequence of destruction would be - last created, first destroyed...?
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
I though the sequence of destruction would be - last created, first destroyed...?
I don't think you can rely on any sort of sequence when it comes to the app going away, especially if you created your CDialog object using new.
Regards,
Alvaro
The world is a dangerous place, not because of those who do evil, but because of those who look on and do nothing. -- Albert Einstein
|
|
|
|
|
HELP!!! lol
after messing about with my pc A LOT (taking out every piece of add-on hardware seperately) i finally managed to install windows XP. So far i was very satisfied of its stability and options. BUT i installed Visual Studio 6 and it installed just fine, except maybe for an error about a DAO dll not being able to register, but i figured Visual C++ wouldnt be needing that anyways, probably just for VB. But when i tried to run Visual C++ it just closes when i try to open a file or a project, so basically when the program tries to show the open/save file dialog. This is for Visual C++, AS WELL as VB, Interdev and Foxpro 
Has anyone experienced this before? Please help me if there is a way to fix this, i'd really hate having to have to install Windows 98/2000 on a seperate partition just for Visual Studio.
Thanks in advance
P.S.: I already tried changing the compatibility mode, it doesnt change a thing
Kuniva
--------------------------------------------
|
|
|
|
|
Kuniva wrote:
after messing about with my pc A LOT
i think you mean that you upgraded your system from win9x to winXP? if so, i think that there is your problem. Windows is getting realy screwed up after an update(as far as i witnessed) from win9x to winXP. try installing windows in one time(without update) so only winXP is finding all drivers and stuff, that may help.
[]D [] []D []
|
|
|
|
|
ow yeah forgot,
your DAO driver is needed while programming... so, it might be a good thing to DO install this driver
[]D [] []D []
|
|
|
|
|
Heh, thanks for the reply, it kinda got sorted already though lol. Like right after i posted this i opened Visual C++ and it worked, and i did not upgrade from Win98, i just erased my harddrive and installed from scrap. And i managed to install the DAO350.dll as well so it all works now. Kinda strange it didnt work at first though... but oh well, Microsoft works in mysterious ways  
Kuniva
--------------------------------------------
|
|
|
|
|
Kuniva wrote:
Microsoft works in mysterious ways
Your ABSOLUTELY right! lol...
[]D [] []D []
|
|
|
|
|
I am wondering if NetRemoteTOD API needs authentication.
I can get the time from a server that is on my domain. I tried it and it works but can I also get the time of a machine which is not on my domain ?
MSD says that no special privilege is required for this API but it does not say anything about authentication. Any help is appreciated.
Thanks
Orcun Colak
|
|
|
|
|
Hi everyone,
I'm going to be building a "real-time" high priority application. I'm looking at using MFC as there are many tools there I would like to use for this application. My question is that, will the application still perform at the speed I need it to (which is polling at a 300mhz sampling rate) using MFC? Or do I need to build a "bare-bones" application to perform the way I need it to.
In addition, If I were to make it a dll which is called via someone else, would I still be able to get the performance that I need. speed is of the essence here. If creating it as a dll, does using MFC in this case cause a performance problem as well?
Any insight/comments/suggestions are greatly appreciated. It will help me to figure out how to approach this effort.
Thanks!
Dan Willis
|
|
|
|
|
MFC is not the issue here, since no Windows application can handle raw data at a 300MHz polling rate. You'll need some intermediate code - presumably a device driver - to poll your hardware, collect that data in packets,and pass it on to your application.
|
|
|
|
|
Jim A. Johnson wrote:
MFC is not the issue here, since no Windows application can handle raw data at a 300MHz polling rate.
actually, I totally forgot that one. You're right. ok, so I write a driver to handle that stuff and reduce the rate to say, 50mhz. Would MFC still be a problem?
Thanks alot!
Dan Willis
|
|
|
|
|
>> Would MFC still be a problem?
to do what exactly?
Most of MFC is GUI based Windows API wrapper classes.
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
Ideally I'd like to use the Arrays Strings, Time, Maps, Sockets, etc.
Not really a whole lot of GUI stuff. I'm trying to keep that to a seperate app.
I just don't want to really resort to using old ansi c and I don't know how to use the iostream stuff and I'm looking for quick solutions for commadline parsing, ini files and so on but every example or open source that seems to be available depends on MFC becuase they use the CString class and other MFC types. That's my real reasoning behind the performance question. If it's that much of a performance hinder, then i'll resort to building the api's I need. I was just hoping that I could find stuff that didn't depend on MFC and I'm not having alot of luck. Kinda looking to not re-invent the wheel if you know what I mean.
Dan Willis
|
|
|
|
|
2Ghz = 2,000Mhz
2000Mhz / 50Mhz polling interval is only 40. That is only 40 clock ticks per polling interval. You won't be able to do much in 40 clock ticks and any IO interupt will kill your polling rate.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Dan, all of those class encapsulations aside from a Socket class is available in STL, i do developement all the time as you prescribed. I almost always choose a non-mfc path for them. The socket api's are the only complicated ones out of that group and even there it's pretty much confined to dealing with sock_addr and hostent structures and functions.
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
Not if you use MFC effectively.
Having said that, you can do as many things wrong in MFC as in native Win32, and MFC doesn't encapsulate all of the Win32 functionality, that you might need.
a) A driver can't reduce the data rate; however, the driver has a guaranteed response time (which you don't have in user mode)
b) even a kernel driver should not _poll_ at 50MHz. What kind of hardware do you use? The acquisition hardware should be able to build packets (e.g. direct PCI bus->memory throughput, without CPU usage), and the driver can make this data available to user mode. Hoever, there is absolutely no guarantee that an applicaiton can always handle this amount of data (whatever it's doing)
c) What is your application supposed to do with the data?
If you go to war, you will destroy a great country a stoned greek chick to the richest man of the world
[sighist] | [Agile Programming] [doxygen]
|
|
|
|
|
Hello All. I've been working with dlls recently and i have some questions regarding the upgrading of dlls and how that affects programs that use them.
1) You have an exe and a dll. The exe uses the dll and does a static load of that dll. If you build a new dll that has additions to it's .h including new exported funcions, will the exe still be able to run with the new dll even if it is not rebuilt?
2) Same situation but you are loading the dll dynamically and getting the function pointers at run time. If you build a new dll with new exported stuff, will the exe still be able to use the dll even though the exe isn't rebuilt?
Thanks in advance!
Dan Willis
|
|
|
|
|
1) maybe not. certainly not safe
2) yes
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
Now,
palbano wrote:
1) maybe not. certainly not safe
I'm assuming that the reason is when you rebuild the dll using the new header, regardless of what you have added (even if it was only a #define 5), there's no garauntee that the Function pointer map will be the same as when the exe was built against the dll. Am I right in this assumption? Becuase this is how I understood dlls to work if you link them statically.
palbano wrote:
2) yes
Dynamic linking on the other is void of this possible issue becuase you are getting the function pointer at run time. Am I correct in this assumption?
Again thanks! I look forward to hearing your input.
Dan Willis
|
|
|
|
|
>> that has additions to it's .h including new exported funcions
actually i was refering to that statement from your first post. Also if you use a DEF file you can order the functions so that could reduce the risk.
"No matter where you go, there your are..." - Buckaoo Banzi
-pete
|
|
|
|
|
Right. That makes sense.  Thanks alot! I really appreciate it. Learn something new everyday!
Dan Willis
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
