|
After several failures to force main CDialog constructor to use parameterized CEdit "child" constructor I came up with this shameless hack!
I use global COLORREF variables and assign them to local variables in the default constructor.
I could just use them but it keeps the rest of the code intact and somewhat sane.
So, is usage of globals in “OOP” on same level as GoTo?
Vaclav
|
|
|
|
|
Couldn't you just change the colors to your desired COLOREF values in the dialog's OnInitDialog() function? Maybe it's not as nice as setting it through the constructor, but it's better than using global variables.
Mike
|
|
|
|
|
Hey i'm new to visual C++ and i'm using windows forms but that forum doesn't seem to get answered.
I'm wondering how to call a method from a class in the form1.h?
so for example:
<br />
<br />
form1.h<br />
<br />
private: System::Void testToolStripMenuItem_Click(System::Object^ sender, System::EventArgs^ e) <br />
<br />
<br />
{<br />
Class test<br />
void test()<br />
{<br />
}<br />
|
|
|
|
|
You should ask the managed C++/CLI one.
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.
[my articles]
|
|
|
|
|
Hi,
I am using right shift operator in my project. The following code snippet shows the sample of the project.
This project is compiled in VS 2005
#include "stdafx.h"
#include <iostream>
#include<conio.h>
using namespace std;
#define JULIAN_ADJUSTMENT 1721425L
int _tmain(int argc, _TCHAR* argv[])
{
long theDate=2453843;
long theAdjustedDays = (theDate >> 32 ) - JULIAN_ADJUSTMENT;
std::cout<<theAdjustedDays;
getch();
return 0;
}
While in debug build, I am getting correct answer: 732418
and in release build, it gives wrong value: -1721425
Please let me know how to resolve this issue in release build.
Thanks in advance
Sumanta
|
|
|
|
|
Sumanta Rout wrote: While in debug build, I am getting correct answer: 732418
and in release build, it gives wrong value: -1721425
Maybe I'm looking at it wrong, but if you divide 2453843 by 232, the result is less than one. Subtracting 1721425 from that will yield a difference of -1721424.99. 
I think the difference between Debug and Release boils down to a signed vs. unsigned issue, but that's just a guess.
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
the debug build seems to have an error lol....
in fact -1721425 is correct since 2453843 >> 32 is 0.
Don't try it, just do it! 
|
|
|
|
|
Actually (at least IMHO) only the release build is working properly.
To keep things easy, let's ignore sign: if you shift a long (i.e. a 4-bytes, 32-bits integer) 32 times then you must obtain zero.
I've seen the disassembly, both of the debug build and of the release build and I suppose that in the latter one code optimization hides a compiler bug (if you turn OFF optimization then the release build behave exactly like the debug one).
In the debug build the compiler translates the right shift operation into SAR assembly instruction. SAR instruction executes the right shift ignoring all but the four least significative ones of the second operand, i.e. does nothing in your particular case. I don't think that standard C or C++ language allows this behaviour.
I think you hit a subtle compiler bug, though I'm not sure about (I'll post the question on the general discussion forum).
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.
[my articles]
modified on Monday, January 21, 2008 10:29:21 AM
|
|
|
|
|
Actually you shouldn't use a 32 bit shift on a 32 bit wide number because the compiler is allowed to return you a wrong result:
(from C language specification [^], 6.5.7 Bitwise shift operators, Semantics)
The integer promotions are performed on each of the operands. The type of the result is
that of the promoted left operand. If the value of the right operand is negative or is
greater than or equal to the width of the promoted left operand, the behavior is undefined.
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.
[my articles]
|
|
|
|
|
Hello!
Is there any API that I can use in my application in order to detect at some moment that another application is trying to install a Windows hook (SetWindowsHookEx) ?
Thanks in advance!
|
|
|
|
|
no this is no api to do so. you could create a global api hook for SetWindowsHookEx.
Don't try it, just do it!
|
|
|
|
|
I guess you are refering to WH_DEBUG. I read the documentation for SetWindowsHookEx again and this seems to be the type of hook I was looking for...
modified on Monday, January 21, 2008 10:18:12 AM
|
|
|
|
|
Urgent help required.
Tons of experience yet unable to see where I go wrong with this one.
Got a CPropertySheet in wizard mode.
One of its pages is scanning the serial ports for a device and for this I elected to use a callback method so that this process is kept asynchronously.
Obviously when this page receives the callback it's (possibly/likely) on another thread so I cast one of the callbacks parameter to the instance and post a user defined message to it, like so:
void CCommsPage::NotifyAPC(unsigned nId, bool bResult, void* pParam)<br />
{<br />
CWnd* pThis = reinterpret_cast<cwnd*>(pParam);<br />
<br />
if (pThis > NULL)<br />
{<br />
pThis->PostMessage(WM_NOTIFY_CB, nId, bResult);
}<br />
}</cwnd*>
When this message is processed by the page I am indeed back on the thread that the port scan was initiated from.
Yet when I then get this page to instruct the wizard to progress to the next page, like so:
<br />
CCommsPage::OnCallBackConnect(bool bSuccess)<br />
{<br />
if (bSuccess)<br />
{<br />
...<br />
<br />
#ifdef _DEBUG<br />
CPropertySheet* pSheet = dynamic_cast<cpropertysheet*>(GetParent());<br />
ASSERT(pSheet > NULL);<br />
#else<br />
CPropertySheet* pSheet = static_cast<cpropertysheet*>(GetParent());<br />
#endif<br />
<br />
pSheet->PressButton(PSWIZB_NEXT);<br />
...<br />
}<br />
}</cpropertysheet*></cpropertysheet*>
The wizard boms out completely when CPropertySheet::PressButton() is invoked.
If I replace the call to PressButton() with...
pSheet->SetWizardButtons(PSWIZB_BACK | PSWIZB_NEXT);
Then the "Next" button is enabled and when I manually click on that button then the wizard does go on to the next page.
That - however - is not an ideal solution and I really want the wizard to progress programmatically.
I've googled and googled and cannot find any article that has the answers that I look for.
I am sure that someone must have had a similar experience. Either that or I am making such a basic mistake that I should reconsider this career.
Someone please help.
|
|
|
|
|
linton samuel dawson wrote: The wizard boms out completely...
Which means what?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
CPropertySheet returns from DoModal() prematurely.
For the record / to reiterate, obviously more pages are 'queued up' which do show when I replace the PressButton() with SetWizardButtons() and click the "Next" button.
|
|
|
|
|
In the OnCallBackConnect() function, how about sending the parent a user-defined message so that it can "press" its own button?
"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
Simplicity in itself (why didn't I think of this?!)
Anyway, have a cigar on me David. This works a treat!
Still baffled as to why it won't work without this 'workaround' but hey...
|
|
|
|
|
In fact, a user defined message is not required I found.
If instead I use ...
GetParent()->PostMessage(PSM_PRESSBUTTON, PSBTN_NEXT, 0);
where I would previously call CPropertySheet::PressButton() (where GetParent() is of course the property sheet) then this works too.
Could this also be the missing clue? CPropertySheet::PressButton() does exactly what I do now but with a SendMessage() instead.
|
|
|
|
|
You shouldnt work with the same Window in different thread via getting it from the original handle. You better post registered messages to the window handle.
Greetings from Germany
|
|
|
|
|
Ehrm.... I don't use the FromHandle() method and I *am* posting messages like you suggest. 
|
|
|
|
|
I'm calling a setup program setup.exe through a bat file. The problem is that although I'm able to execute the setup program the command prompt lies in the background. The intent is to get rid of this prompt; so that if one clicks on install.bat file the installation is shown in the foreground as going smooth without having the window due to running the bat file visible. Note that the bat file is a must as it contains a handful of dos command that has to be executed around the installation. Could there be any other way to package this stuff? Please help.
|
|
|
|
|
Do you control the setup program? If so, is there some reason the DOS commands can't be run from within your Setup program via CreateProcess with SW_HIDE?
Judy
|
|
|
|
|
Yes The bat file controls the running of the setup program.
|
|
|
|
|
tom groezer wrote: Yes The bat file controls the running of the setup program.
That's not quite what I meant when I asked if you controlled the Setup program. Is it your setup program? Did you write it? If that answer is yes, see the second sentence of my previous reply.
"Do you control the setup program? If so, is there some reason the DOS commands can't be run from within your Setup program via CreateProcess with SW_HIDE?"
Judy
|
|
|
|
|
Adding to Judy's reply, check if ShellExecute() would be of any use to you.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
