Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Introduction:
Lots of hot topics are covered in the Discussion Forums on CodeGuru. If you missed the forums this week, you missed some interesting ways to solve a problem. Some of the hot topics this week include:
- Why do I get an error with a simple CTime code?
- Do I have to keep the DSW and DSP file under the source control?
- How often have you used ‘goto’ in the last five years?
- Should I have to use a TXT file when implementing a Tooltip control?
|
Thread:
geo_m has some problem with a simple CTime code. Take a look.
I want to create a CTime object with this line of code:
CTime time(1970, 1, 1, 0, 0, 0)
In debug mode, an assertion failure arises, even if in MSDN it says the values used in constructor are in the valid ranges. Stepping into the constructor, I found that _mktime64() returns -1. Can somebody tell me what is going on?
So, how can this be? This code works perfectly for me.
Well, the problem could be with the time zone of geo_m. If you construct your CTime like that, some adjustments might need to be made for daylight savings (DST) and for time zones. For example, CTime time(1970, 1, 1, 0, 0, 0) in London would be CTime time(1969, 12, 31, 19, 0, 0) in New York if there’s a five-hour difference.
Some things to remember while using CTime are:
- When using the CTime(time_t time) constructor, time MUST be considered in UTC coordinates.
- When using the CTime(int nYear, int nMonth, int nDay, int nHour, int nMin, int nSec, int nDST = -1) constructor, time values MUST be considered in time zone coordinates.
|
Thread:
martin_craigen has just started to work with SourceSafe. He has some questions. Maybe you can help him find the solutions.
We have just started using SourceSafe to store my Visual C++ projects. There are many programmers sharing the database. I know we have to keep the .dsp files under source control, but I am not sure about the .dsw files - do I need to keep these as well? An annoying thing that happens, though, is that I want to use the automatic check-out facility by ticking "Use read-only flag for files that are not checked out". However, when I do this and open Visual Studio, I keep getting prompted to check out the .dsp and .dsw files. Why does VS do this? I am not explicitly changing these files. Does VS automatically change them on opening? It is good to be prompted when I DO make a change to project settings, but really annoying to have to keep clicking "no" on startup. Any idea how to get around this?
It’s true that you can get away without adding the DSW file to SourceSafe, but you are probably better off keeping it under source control. This is especially true for workspaces with many projects. The project build dependencies are kept in the DSW file and if the project is going to be shared by a development team, it will be required in order to keep the build process reliable from one developer to the next. It’s kind of like not putting the makefile under source control—it’s a very bad thing.
You’ll find that, once you add the DSW files to VSS, it will want to change them at first as all the project interdependencies are added and source control links added. But, once the workspace is stable, you’ll find that you almost never have to check it out, unless you are adding projects or changing the dependencies.
Besides that, it sounds as though your source control is mucked up. That could be a reason why you always got the annoying messagebox. You have to be very careful when adding projects to SourceSafe. The DSW is essential to add to SourceSafe because it also contains the source safe paths to each project. This is so that Visual Studio knows where the projects are. Always add projects to SourceSafe from inside of VC++; in other words, by means of the SourceSafe toolbar.
|
Thread:
John E started a very interesting poll about the usage of goto. The question is how often have you used it in the last five years.
Okay - it's not very grand at all but here goes - the purists among us would prefer a world without 'goto'. The pragmatists among us think that it's 'sometimes' the right tool for the job, so let's have a vote. How often have you used 'goto' in the last five years or so? Be honest - this is an anonymous poll so noone needs to be embarrassed or fear for their reputation! It's just a survey. Noone will get hung!
Here are some comments:
“I use goto regularly when programming in C (for cleanup). I have probably also used it in C++, but the product I’m working with is mostly written in C. It’s a Windows security product (PKI), running on WinNT/2000/XP clients. The name is RSA Keon Desktop or TFS Desktop.”
“I also use goto for cleanup. In my case, I implement both cleaning up and error checking via a #define’d macro that uses goto. It’s the only use I’ve ever found for it—but I do use that macro in every program I write.”
Do you also use goto for cleanup? Maybe you can tell us whether you use goto or not. Take a look at the thread.
|
Thread:
eagle1 has implemented a tooltip control in his application. This tooltip controls relies on a TXT file which contains the tooltips. Now, is there a better way to handle those tooltips?
Well, it's been a long time since I used VC++ and I started again in December. Now, I have made a little "encryption" program using the Julius Ceasar algorithm in VC++ and I added a Tip of the Day component when the program starts. The thing is that this component is relying on a file called Tips.txt but what I want to know is whether there a way to get rid of the tips.txt and somehow make the component look for the tips internally (you know, so I don't have to pack the EXE with a TXT file)?
Well, the best technique is to use resources that are more flexible and can be stored in seperate DLLs. Then, you can simply use the LoadString() function to access the strings in your table.
