|
I found this article quite instructive.
http://bit.tekotago.ac.nz/~sam/teaching/se2/lectures/helplecture/helpmain.html
It gives step-by-step instruction on how to create help files in Windows 95 style.
As Tim said, you should switch to *.chm which has a nicer look. Check this article out for how to make *.chm step-by-step.
http://www.mvps.org/htmlhelpcenter/char_hhw.zip
|
|
|
|
|
Hi All. First I want to thank all the helpful people here. I've finally succeeded in writing my first decent windows program! Its a multithreaded program that gets data from a serial device! I have a bit of tidying up and error handling to do but its doing the job nicely at the moment!
However I have this problem when I switch it over to release mode! I have a dll as well that I compile in release mode then run the application. Everything seems fine until I try and update a list of records available in the serial device to a listbox in my dialog. In debug mode this works perfectly, however in release mode it will only list the first record (there's about 120) at which point it kills the thread practically straight away!!
Any tips or advice on how to track down whats causing the problem, or what I should look at in order to diagnose whats causing it?
Thanks
-Mark
|
|
|
|
|
Maybe you put some vital function call into assert() or ASSERT()?
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Well I havent used any assertions directly in my code! However I was getting assertion errors in this thread at one stage but I managed to diagnose the problem and fix it! Maybe the functions I am using are doing it although I dont know why?
Thanks for the tip though, it'll give me something to look for
|
|
|
|
|
Ok things are getting really screwey now!
I located the problem in the thread where it stops. I construct a message packet to send to the serial device with a bunch of 8 bit words. These include the address of the device and the command to execute!
On the first loop these values are correct but it appears to be trashing them on the 2nd. I looked at the reply from the trashed message and it was saying invalid address, implying to me that the values I was sending werent correct. To look at the values it was sending to the device I perform an itoa() conversion and post it in a message to my dialog to dispaly in a text box. It appears that if I run this conversion on the values with itoa . . . the program works fine!
Playing around with different things I am getting some very odd results and other things like if statements failing, but when I check the values that the satement was checking manually it should have passed!?
It sounds like I've done something I probably shouldnt have somewhere!
|
|
|
|
|
Hi,
Do ensure that all variables (buffers, pointers, structure instances) are
initialised in the correct context(i.e. declaration or first usage).Moreover,
after you read each record from the serial device and populate the list in
your application, try reinitialising the buffers which are used in the reading
(from serial device) and writing(to list) operations.
If the records that you are reading are of varying length then the code should
take care of reading and writing the biggest record; i.e. the read/write
buffers should be able to accommodate any record of any size.
In my opinion, the only way to come out of this 'screwy situation' is to
apply the brute force technique of debugging. You may need to put in calls
to fprintf() or printf() or OutputDebugString() to monitor the steps of the
code in release mode.
Points mentioned above are not solutions to your problem but I sincerely
hope the suggestions help.
With best regards,
Sayan
Email:sayanmukherjee@indiatimes.com
|
|
|
|
|
Ok in reading MSDN I have now found out that it appears to be some optimization problem!?
By putting
#pragma optimize("", off)
and
#pragma optimize("", on)
around the code for the thread in question I find that the function now works! Its got me stumped! I might just leave it at that, its a solution I suppose!
|
|
|
|
|
All you are doing is putting off the bug till later. You know you code is buggy. Either find it now during development or rush to fix it later after the software has been shipped.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
|
In many sample code snippets I see an "L" function... macro ... or something operating on a string and I can't figure it out. Its a little tough searching MSDN for "L" so can sombody tell me what it is? here is a code snippet (Its the L after the '=' and before the '"' ):
_bstr_t szModTextBody;
szModTextBody = L"Hello World";
|
|
|
|
|
L is not a function - it's a prefix which signals that string which is prepended to is an UNICODE string.
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Just a little correction: Not necessarilly UNICODE, but rather wide-char. Of course, on Windows wide char is UTF-16, but on some other platforms it is not. For instance, on Unix, sizeof(wchar_t) == 4
I vote pro drink ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
So why do they call their widechar-encoded strings? UTF-32?
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Depends on the implementation, I guess. C++ standard does not bind wchar_t to any particular encoding.
And yes, there is UTF-32, although it is not that popular 
I vote pro drink ![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
|
|
|
|
|
Of course, on Windows wide char is UTF-16...
Maybe I'm wrong, but I don't think Windows wide char encoding is UTF-16, as UTF-16 has escape sequences for characters with values above than 65535. This has the implication that the enconding for some characters can run to more than one wide char, which to the best of my knowledge is not suppoorted in any manner by Windows. Please correct me if this is not true.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Windows is Unicode 2.0. This might be prior to the UTF-16 escape sequences.
Generally, UNICODE under windows is UTF-16, but they very well could be lacking the escapes.
Tim Smith
I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
|
|
|
|
|
What i found on the net is that Windows uses UCS-2, which is UTF-16 without the escaping stuff (so hopelessley restricted to 65536 symbols). I'd like to find a more conclusive statement of this in microsoft.com.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
I am trying to derive from CControlBar and am not having much success, but slowly understanding why things work the way they do so i'll figure it out soon. I hope.
Heres my problem...When creating a new class derived from CControlBar the way I see it I have 2 options in creating the class.
1) Derive from MFC CWnd and later change the class from CWnd to CControlBar
2) Generic, but then I have to add the special ClassWizard comments on my own and that all takes time.
To be fair I tried both methods and neither does what I need.
When you right click on a class to add virtual functions you would usually expect to get a list of all available functions. However it seems when deriving from CControlBar (which isn't complicated enough for me  ) it virtual functions aren't available, only CWnd's are....
I have modified *.clw file but cannot for the life of me figure out if what i'm trying to do is even possible...???
Am I going to have to keep finding the afxext.h barcore.h (i think) files and copy pasting...or is there a more classwizard friendly way of doing things...?
This is driving or is that deriving...? me INSANE!!!
Any suggestions...?
Thanx in advance.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
Firetruck the ClassWizard - you don't need a fancy dialog to add virtual function. ClassWizard does nothing magical that you couldn't do yourself.
Which virtuals are you overriding?
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Tomasz Sowinski wrote:
you don't need a fancy dialog to add virtual function.
Your right...I don't need it, but it's there for a reason and that reason i've kinda got attached to.
Tomasz Sowinski wrote:
Which virtuals are you overriding?
A while back when deriving from a custom class I wrote I noticed nothing was happening when the class was instantiated, when I (in the child class) did the following to all the virtuals stuff started happening.
virtual OnCreate(...){ return CParent::OnCreate(...); }
I never did figure out why this was so, but at that time I couldn't care...it worked.
I'm thinking my lack of success with derived CControlBar's might have something to do with preceding. I figure i'll override all the virtuals until something starts happening.
Overriding all the cirtuals by hand will be time consuming and annoying. I'm really not looking forward to copy/paste either. Even if I just make them all inline so I avoid having to go back and forth between h and cpp
's i'm lazy that way and would rather spend my time coding... 
It's so frustrating...I can't even start programming what I want until the control bar is functioning.
Suggestions, ideas...?
Cheers!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
OnCreate should not be virtual. It's a message handler for WM_CREATE and it's wired to API through the MFC message map.
You have to ensure that BEGIN_MESSAGE_MAP has the reference to real base class. This is easy to overlook when deriving from CWnd and changing base class to CControlBar.
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Tomasz Sowinski wrote:
OnCreate should not be virtual
Sorry I meant Create(...)
BEGIN_MESSAGE_MAP(CToolbarEx, CControlBar)
I think i'm doing that properly. Still no luck on the CControlBar showing it's own virtuals.
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
OK. There's one more thing you may find helpful. I've found that *sometimes* newly overriden virtual function doesn't get called - it's easy verifiable; just put the breakpoint into it. Rebuilding always fixes this problem.
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
|
Tomasz Sowinski wrote:
I've found that *sometimes* newly overriden virtual function doesn't get called
What exactly do you mean...?
I think you mean what I was saying earlier...
The last time I derived from a class I found I needed to call the virtual parent functions.
It just so happens this is the problem I am having with my current project also. I'm oging to have to re-write the virtual functions or atleast call the parent version. I'm thinking by doing this my grippers and such will start to show up slowly.
Tomasz Sowinski wrote:
it's easy verifiable; just put the breakpoint into it. Rebuilding always fixes this problem.
Verifiable...? Like as in verify this is happening...? I'm sorry my english stinks...I hated school.
I verified this was happening by placing AfxMessageBox() in the CControlBar::OnSizeParent() and other functions...they weren't getting called.
Rebuilding fixes this problem...?
Rebuild All...?
Thanx!
"An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
|
|
|
|
|
HockeyDude wrote:
What exactly do you mean...?
I mean that behavior I've described happens from time to time, especially when I'm dealing with deep class hierarchies.
HockeyDude wrote:
The last time I derived from a class I found I needed to call the virtual parent functions.
Wait, wait, wait. 'Paren functions' are *not* called automatically. To make sure we're talking about the same thing, consider the following class hierarchy:
class B
{
public:
virtual void foo() { printf("In B::Foo\n"); }
};
class D : public B
{
public:
virtual void foo() { printf("In D::Foo\n"); }
};
B* pb = new D;
pb->foo();
You're going to see 'In D::Foo' only. If you want both strings to appear, you have to explicitly call B::Foo in D::Foo. The fact that function is virtual doesn't imply anything about parent class implementation being called (a'la C++ constructors/destructors).
So are we broadcasting on the same wavelength?
Tomasz Sowinski -- http://www.shooltz.com
** If you're going to rape, pillage and burn, be sure to do things in that order. **
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
