|
TeslaShock wrote: and then goes the reversed RGB data
Depends on the format of the bitmap. There are at least half a dozen common BMP formats, all documented.
|
|
|
|
|
well, i read more about formats...but it seems to me that i do everything right, and my pictures are 24bit so no color table should be used there. The only difference is some formats have two unused bytes or one...after the rgb data... BUT in that case...during a read i would get the corrupted data! but...i read many many thousands of rgb values and all are ZERO...
i mean its not a problem of shifting the values... it just reads zeros! but i use the same MS Paint editor! and i do the bitmap copy/paste operations with that editor only...and copy from other pics... so what could be the problem...strange... ? 
|
|
|
|
|
Hi
I designed a dialog box using "DlgProc" to handle message.
CMyDialog::CMyDialog()
{
...
GetOFN().lpfnHook = DlgProc;
...
}
UINT CALLBACK DlgProc(HWND hDlg, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
switch (uMsg)
{
}
return 0;
}
BOOL CMyDialog::OnInitDialog()
{
}
But OnInitDialog() is never called, how can I fix it
Best regards,
|
|
|
|
|
Who and why should call it?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I have a "CButton" which pointer should be available.
I plan to use GetDlgItem() to get it. But this function only functions correctly in "OnInitDialog".
Thanks,
|
|
|
|
|
transoft wrote: I have a "CButton" which pointer should be available.
Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button.
transoft wrote: I plan to use GetDlgItem() to get it. But this function only functions correctly in "OnInitDialog".
No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense.
I think you really need to read a good book about the MFC because it seems you are totally confused about a lot of things. We won't be able to help you unless you grasp the basic concepts firsts.
|
|
|
|
|
"Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button."
From what you said, you have something to learn and they are not IN a good MFC book.
"No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense."
From what you said, you have something to learn.
|
|
|
|
|
transoft wrote: "Why do you need to have the pointer available and where ? If it is in your dialog class, you could simply associate a class member with that button."
From what you said, you have something to learn and they are not IN a good MFC book.
What do you mean exactly ? If you need to access your button control, why don't you simply associate a variable with it ?
transoft wrote: "No, that's wrong. Why would that function only work inside the OnInitDialog function ? That doesn't make any sense."
From what you said, you have something to learn.
Again, unless you express yourself very poorly and I didn't understand you at all, calling GetDlgItem can be called from any function from your dialog class as long as your dialog has been created. I'm sure about this because I've been using that function quite often in such situation. Besides, what would prevent this function from working if not called from OnInitDialog ? What if you call a function from OnInitDialog which call itself the GetDlgItem ?
|
|
|
|
|
Can you use "GetDlgItem" in a "Dialogbox" class' construction?
CMyDialog:CMyDialog()
{
GetDlgItem()l ---->Wrong
}
|
|
|
|
|
No, because the dialog is not created. That's what I meant in my previous message.
But maybe you could explain a bit better what you are trying to achieve and what is the reason behind that, because it feels like you are trying to find a 'hack' around something which could probably be achieved in a much simpler way.
|
|
|
|
|
It looks like you are a bit confused (and I'm too because I don't really get your question).
Are you using the Win32 API directly or are you using the MFC's ?
If you are using the Win32 API, there is no magic done for you. You will need to handle the WM_INITDIALOG message in your window procedure and call the function yourself.
If you are using MFC, what are you trying to achieve exactly here ? You need to have an entry for the OnInitDialog function in the mesasge map (this can be done through the wizard).
|
|
|
|
|
Because MFC dialogbox can not do everything you want it do for you. You have to use special "DlgProc".
You never did some programming mixing use of MFC and Win32 API?
|
|
|
|
|
transoft wrote: I designed a dialog box using "DlgProc" to handle message.
...
CMyDialog::CMyDialog()
{
...
GetOFN().lpfnHook = DlgProc;
...
}
Unless you've written something by yourself that you named GetOFN(), I hope you are aware that the letters 'OFN' in GetOFN() is an abbreviation for the OPENFILENAME struct and that your dialog should derive from CFileDialog.
Otherwise you'll have to explain this a bit further.
Regarding the use of the lpfnHook member, you'd better read the documentation[^], especially the part about lpfnHook. It clearly states that you need to include OFN_ENABLEHOOK among the flags in the Flags member of the OPENFILENAME struct.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
This part works just fine. What I need is to get OnInitDialog() called.
|
|
|
|
|
transoft wrote: This part works just fine.
What part?
Never mind.
transoft wrote: What I need is to get OnInitDialog() called.
Well, you haven't shown anything that will call your OnInitDialog().
It won't get called by magic.
What base class did you use for your dialog?
Is it really meant to be a file dialog?
What flags have you set for the Flags member of the OPENFILENAME struct?
How do you set up and show the dialog to the user? Calling DoModal()?
Why do you think you need the hook since your using subclassing? It mixes Win32 API and MFC.
The most important question is "What Are You Trying To Do"?
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
What base class did you use for your dialog?
CFileDialog
Is it really meant to be a file dialog?
Yes,
What flags have you set for the Flags member of the OPENFILENAME struct?
I did as you said in the last comments.
How do you set up and show the dialog to the user? Calling DoModal()?
Yes, I called "DoModal()"
The most important question is "What Are You Trying To Do"?
I am trying to display bitmap image in a CFiledialog attached with "CStatic" control. This image should be changed whenever I select a different bitmap file.
|
|
|
|
|
Okay.
First of all: throw the hook thing in the trash can; it's a Bad Idea.
It's like refusing to use a caterpillar and favour a spade when digging a ditch.
MFC already makes use of the hook and that's why your functions doesn't get called; you've pulled the rug for MFC, so to say.
Have a look at these two articles to get your customized file dialog up and running: here[^] and here[^].
Override the CFileDialog::OnLBSelChangedNotify() to know when the user selects another file and your image should be updated.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
|
I'm going to take a fast, quick, guess but it looks like you are taking over the dlg procedure and not letting it do default processing. If you hook, you need to call the previous procedure in the chain.
|
|
|
|
|
|
Looking at the MFC source, it appears that your shouldn't be hooking this function if you derive from CFileDialog and that you should get an assert in debug mode. Furthermore, since CFileDialog is hooking this, I fail to see why you need to.
|
|
|
|
|
Joe Woodbury wrote: Looking at the MFC source, it appears that your shouldn't be hooking this function if you derive from CFileDialog and that you should get an assert in debug mode. Furthermore, since CFileDialog is hooking this, I fail to see why you need to.
Exactly, that's my point as well[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
hi
i when i compile cppunit-12.1 in visual studio 2005, i got this error message. how to solve this problem?
error C3505: cannot load type library '{80CC9F66-E7D8-4DDD-85B6-D9E6CD0E93E2}'
and could you please explain me what the following line means?
#import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("7.0") lcid("0") raw_interfaces_only named_guids
thank you.
sumani
|
|
|
|
|
rsumanan wrote: hi
i when i compile cppunit-12.1 in visual studio 2005, i got this error message. how to solve this problem?
error C3505: cannot load type library '{80CC9F66-E7D8-4DDD-85B6-D9E6CD0E93E2}'
What about documentation [^]?
rsumanan wrote: and could you please explain me what the following line means?
#import "libid:80cc9f66-e7d8-4ddd-85b6-d9e6cd0e93e2" version("7.0") lcid("0") raw_interfaces_only named_guids
What about documentation (reprise) [^]?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I want to write the code that notifies me, when new socket is established? Does windows generates any kind of event when new socket is established?
Thanks in advance.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
