|
I have a small dialog based code that proceeds through several dialogs to input data into a database. I have developed this on two separate machines and it works fine, when I copy the files to a third machine the code fails to open the second, or any subsequent, dialogs. I am using peekmessage to handle WM_DESTROY.
Many Thanks for any suggestions
|
|
|
|
|
This could be due to a number of reasons. Anything from invalid database connection, to differences in Operating Systems.
A little more information is needed to trace this problem down.
I Dream of Absolute Zero
|
|
|
|
|
Here is the code that causes problem, CIOC_Login is a CDialog based class:
<br />
while (control.Login == FALSE)<br />
{<br />
dlg0 = new CIOC_Login();<br />
m_pMainWnd = dlg0;<br />
nResponse0 = dlg0->DoModal();<br />
::PeekMessage(&msg,NULL,WM_QUIT,WM_QUIT,PM_REMOVE);<br />
...........<br />
...........<br />
delete dlg0;<br />
}<br />
....<br />
....<br />
while (nControl !=2) <br />
{<br />
int nResponse1;<br />
nResponse0 = dlg1.DoModal(); <-- Doesn't open!<br />
::PeekMessage(&msg,NULL,WM_QUIT,WM_QUIT,PM_REMOVE);<br />
|
|
|
|
|
MSDN articles Q138681 and Q253130 might be of interest to you.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Thanks, deleting the reference to m_pMainWnd solved the problem.
AndyB
|
|
|
|
|
Hello,
I have a MDI type application with 2 different views. I create the CDialogBar in my CChildFrame class so the DialogBar is viewed with in the child frame. I want to catch WM_LBUTTONDOWN messages for the dialog bar but can't. I have tried to catch this msg in CChildFrm::WindowProc and other obvious areas but never see the message.. I used spy++ and can see a WM_SETCURSOR msg being sent to the ChildFrame with a WM_LBUTTONDOWN as part of the WM_SETCURSOR message (kinda confusing).. Any ideas?
Rob
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Never mind, I figured it out.
Whoever said nothing's impossible never tried slamming a revolving door!
|
|
|
|
|
Ok, so I'm writing a multi-user database app. The downside is that I am interfacing with Access databases. Now it's not like hundreds of users, but maybe tens of users, so here is my design dilemma...
Should I:
A. Create a connection to the database and keep that connection open during the application lifetime.
B. Create a connection to the database, buffer the data, close the connection, and then only reconnect to commit changes.
C. Open and close the connection each time data is updated WITHOUT buffering the data.
D. Some other idea?
~Nitron.
ññòòïðïðB A start
|
|
|
|
|
I guess the methods of keeping your "connetion pool" will differ, depending on your software circumstances.
I would never by default consider C., because it can eat up considerable amount of time each time you connect. But this may be necessary on a stateless Client/Server program.
Personnally, I tend to keep a db connection, disconnecting after a specified amount of inactivity, then reconnect when required.
I Dream of Absolute Zero
|
|
|
|
|
The answer really depends upon the frequency that the user will hit the database. Remember, connecting to a database is very expensive, so if the users will be accessing the database more than every couple of minutes, it makes sense to connect and keep the connection open.
onwards and upwards...
|
|
|
|
|
I have some problem. I'm not sure how to do a program that synchronize the time for five computers.
One computer will be a Master and get the time with ntp. And then sent a signal to the other four computer for example every 10 second.
Is there someone that can help me get started and give me some hints how I should do?
/stefan
|
|
|
|
|
Rather than implement a push design, why not go for a pull design? You could create a scheduled task on each of the computers that periodically started a .BAT file that contained the appropriate net time command.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Hi guys,
I have stumped through something that I think should be easy to do, but yet to make it work. Basically, I have a plan edit control (CEdit) which I want to make it un-editable, no text, space etc can be put it. The content will only be changeable by the app internally, using SetWindowText().
I can't make it Read-Only as it will grey out the content area, I still want the text inside the edit control selectable. Disabling the control greys out the whole box too. I had a thought to override OnKeyDown and OnKeyUp messages for this particular control but maybe I had them written wrong.
in the class declaration, .h file,
afx_msg void OnKeyDownEdit1();
in the .cpp file
BEGIN_MESSAGE_MAP(MyMainDlg, CDialog)<br />
ON_WM_KEYDOWN(IDC_EDIT1, OnKeyDownEdit1)<br />
END_MESSAGE_MAP()
void MyMainDlg::OnKeyDownEdit1<br />
{<br />
}
It'd be great if someone could point me out where I did wrong here. Or if completely wrong, what shoudl I do instead.
Thanks alot
|
|
|
|
|
you need to derive your own edit class from CEdit , and in which you handle the keystrokes.
or if it's always a read-only control, maybe a CStatic derived class can be used.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
CEdit includes a SetReadOnly( )[^] function.
Wenn ist das Nunstück git und Slotermeyer? Ja! Beierhund das oder die Flipperwaldt gersput!
|
|
|
|
|
J.B. wrote:
I have stumped through something that I think should be easy to do, but yet to make it work. Basically, I have a plan edit control (CEdit) which I want to make it un-editable, no text, space etc can be put it. The content will only be changeable by the app internally, using SetWindowText().
Then why not just use a static control? It satisfies all of your requirements.
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Mr.Crow if you dont me mind saying that you shuold give a proper ans or nothing at all. Do you know that you cant have scrolling effect with the static control, Or horizontal scrolling with the static control. What if he just wants to display some long text that can only be viewed and not edited?? Did you consider this? or were you giving with some unwanted suggestion?
Any ways the solution to the problem is checking the Read-only in Styles of the edit box.
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
Goodness gracious, someone woke up on the wrong side of the bed this morning! Are you always so tactfulless on Thursdays?
Did you know that using the ES_READONLY style also has the side effect of graying the edit control? I suppose that's just as incorrect as my answer. Yes?
A rich person is not the one who has the most, but the one that needs the least.
|
|
|
|
|
Now, now, chaps. Let's have some decorum in here. Anyone would think you were all Java developers*
One possible solution is to use ES_READONLY, but handle the WM_CTLCOLORSTATIC message in the dialog, (or the reflection of it, in the control). The edit control sends this message, rather than WM_CTLCOLOREDIT, if it is either disabled, or read-only.
You could then return an appropriate HBRUSH value to change the grey/gray background accordingly.
Steve S
*Please, no flames about Java. I've just been told who my new line manager is, and he's an anti-MS pro-Java pro-linux man. Given that I work mainly in C++ using ATL on COM+ components, life is about to get more interesting, unless I find an alternative form of employment
|
|
|
|
|
ok what ever you think.
"When death smiles at you, only thing you can do is smile back at it" - Russel Crowe (Gladiator)
|
|
|
|
|
I think you'll find it much easier to make the control read-only and handle the drawing of the edit control to make it look like it's a non-read-only control. Handle WM_CTLCOLORSTATIC and do something like this:
LRESULT CMyDlg::OnCtlColorStatic
(WPARAM wParam, LPARAM lParam)
{
HDC hDC = (HDC)wParam;
HWND hwndCtl = (HWND) lParam;
UINT uCtrlId = ::GetDlgCtrlID (hwndCtl);
if (uCtrlId == IDC_MY_EDIT) {
CDC *pDC = CDC::FromHandle (hDC);
pDC->SetBkColor (RGB (255, 255, 255));
return (LRESULT) (HBRUSH) m_brushBkg.GetSafeHandle();
}
return Default();
} Of course, you should use GetSysColor() instead of the hardcoded constant RGB (255,255,255). You'll also need to create/destroy the background CBrush within your dialog.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Thanks Ravi, and the other guys who have posted to help,
really appreciate it.
Ravi's suggested method seems to work for my needs for now. In addition to the original codes, I also have to re-initialise the brush. Without doing that, the area that is outside the text rectangle area (depends on the font size that is set) will be all in black.
LRESULT MyDlg::OnCtlColorStatic(WPARAM wParam, LPARAM lParam)
{
HDC hDC = (HDC)wParam;
HWND hwndCtl = (HWND) lParam;
UINT uCtrlId = ::GetDlgCtrlID (hwndCtl);
m_brushBkg.DeleteObject();
m_brushBkg.CreateSolidBrush(RGB (255, 255, 255));
if (uCtrlId == IDC_LABEL_DISPLAY) {
CDC *pDC = CDC::FromHandle (hDC);
pDC->SetBkColor (RGB (255, 255, 255));
return (LRESULT) (HBRUSH) m_brushBkg.GetSafeHandle();
}
return Default();
}
|
|
|
|
|
I think you're better off creating/deleting m_brushBkg just once (outside the handler). That would be more efficient.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
Thank you Ravi,
for this further suggestion.
Cheers
|
|
|
|
|
Hello
I want to create a small and simple AVI animation to be used by the CAnimateCtrl in a dialog. I have created the series of bitmaps that I want to use, but I can't find a small and simple tool (preferrably free since this is a one time problem) that does the job.
Since the dawn of DivX the web is bloated with information on AVIs that is useless for this simple job, and all the old postings I have found is from the mid-90's and I can't find the tools.
I have tried the CAVI32 program, but it changes the pink background to white, which makes all my whites transparent (with the effect ov having gray papers floating through the air).
Does anybody have a suggestion?
|
|
|
|