Serious Tip Of The Day
Author
Saw the funny Tip of the Day thread going on, and I thought it would actually be a good idea to have a thread with short tips, here goes mine:
Never burn your Demo onto a CD, to run off from that CD, if the Demo opens files with the write attribute ON, it will of course fail.
Look into the Win32 API Functions:
- GetModuleFileName
- GetDriveType
...so that you can detect if the current drive is unwritable, and at least give the user the option to write the log files to another Drive (or detect it yourself)....
In the .NET Forms editor, never set your timers to Enabled = true if you set an interval for them. The runtime will start the timers during initializing of your app. It took me a few hours before I figured it out.
Toolmaker
Toolmaker
Check if all your binaries are up to date and compatible with each other. Nothing sucks more to be debugging an obsolete binary because somewhere along the lines of a long build some part of your project failed to compile, and you overlooked the error message :)
Make sure to leave newlines at the end of your files.
This seems trivial, but when you decide to compile on GCC/MinGW and see 50 warnings about missing newlines, it is not cool.
This seems trivial, but when you decide to compile on GCC/MinGW and see 50 warnings about missing newlines, it is not cool.
Author
If you seem to have Memory Leak problems, visit Fluid Studios, they have and excellent package to detect them, and it's free [wink]
Click here and go to the bottom of the page (MMGR).
If you still have dificulty tracing bugs, have you ever looked into the option of generating a "crash dump" when a critical error occurs?
This "minidump" (usually around 40Kb or less) could be sent to you from the users, and you can use it to trace the bug while in the Visual Studio IDE, to pinpoint its location, callstack, etc...
Click here to get you started on the subject.
Click here and go to the bottom of the page (MMGR).
If you still have dificulty tracing bugs, have you ever looked into the option of generating a "crash dump" when a critical error occurs?
This "minidump" (usually around 40Kb or less) could be sent to you from the users, and you can use it to trace the bug while in the Visual Studio IDE, to pinpoint its location, callstack, etc...
Click here to get you started on the subject.
When attempting to execute Script-side functions in javascript (using SpiderMonkey) you have to call JS_ExecScriptPart(JSEXEC_PROLOG) before you attempt to call the function by name (JS_CallFunctionName). This is undocumented and was the casue of many hours of head scratching to figure out why it didn't work.
Another "undocumented" GOTCHA:
ListView controls
LVS_REPORT
Win32
If you create a ListView control with the LVS_REPORT style either by hand or through the IDE, you must insert at least one column into it, or none of your ListView items will be visible.
ListView controls
LVS_REPORT
Win32
If you create a ListView control with the LVS_REPORT style either by hand or through the IDE, you must insert at least one column into it, or none of your ListView items will be visible.
Don't use CreateThread() if your win32 app uses the multithread library... use __beginthreadex() instead...
In vbscript for loops end in next (rather then next [varname] as used in other basics)
eg (in vbscript)
for x = 0 to 100
msgbox x
next
rather then (in visual basic)
for x = 0 to 100
msgbox x
next x
eg (in vbscript)
for x = 0 to 100
msgbox x
next
rather then (in visual basic)
for x = 0 to 100
msgbox x
next x
When using STL containers make sure your type has an appropriate default & copy constructor, [destructor], and an assigement operator for things to gel well.
If there isn't an appropriate one, or you need polymorphic behaviour in STL containers then store pointers to the type but you will be responsible for deleting any dynamically allocated memory that any of the pointers in the container refer to.
The containers will only delete the pointers and not what it points to. There is a way of getting round this limitation by instead of storing raw pointers use smart pointers that will delete the object it refers to at the wright time.
[Edited by - Magmai Kai Holmlor on June 30, 2004 9:44:21 PM]
If there isn't an appropriate one, or you need polymorphic behaviour in STL containers then store pointers to the type but you will be responsible for deleting any dynamically allocated memory that any of the pointers in the container refer to.
The containers will only delete the pointers and not what it points to. There is a way of getting round this limitation by instead of storing raw pointers use smart pointers that will delete the object it refers to at the wright time.
[Edited by - Magmai Kai Holmlor on June 30, 2004 9:44:21 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement