|
I'm leaning towards a permission-related issue. To verify, dummy up a little program that does nothing but create and write to a file on the network. Does that uncover anything?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Took a while but wrote a little app for them. There are 3 locations this happens at so far. The test app had the same result. It wasn't an CFile or CArchive exception rather it was caught in the CException catch block.
They all have the problem when they write to the server. When they change the path so that it writes to their C:\ drive there isn't a problem.
Thanks for the bandwidth!
ed
The absence of evidence is not evidence of absence.
|
|
|
|
|
I have noticed a "visual scrolling" problem with owner-draw list boxes (both mine and others) in XP. This occurs with both stand-alone list boxes and ones associated with a combo box. The problem occurs if the My Computer | Properties | Performance Options | Visual Effects | Smooth-scroll List Box option is checked. The animated scrolling generated by windows is okay unless you click on the scroll bar to generate page-up/page-down messages. With this, the scrolling animation visually appears to be going in the opposite direction as expected...but when the animation terminates, the appropriate update has occurred (e.g. the expected items are visual). This is quite obvious when the list box size is large enough and the items are different in appearance. This does not appear to occur with non owner-draw list boxes.
I cannot find any reference to this bug but it is clearly reproducible. Is anyone aware of a fix?
|
|
|
|
|
Can someone help me. I have two recordsets that are opened (ADO)
AdRecordSet and AdTimesRecordSet.
The data is then combined by the field AdID into a class / recordset SiteAdInfoSet (the instance is called CAddInfoSet)
I would like to sort CSiteAdInfoSet by m_NrPlays (int) in descending order (field came from AdTimesRecordSet.. I want to re-store the data back into CsiteAdInfoSet as to keep changes to a minimum.
I hope this is clear
Thanks.
TomH
|
|
|
|
|
Does the recordset have an SQL query (e.g., SELECT <field> FROM WHERE ...) associated with it? If so, just add ORDER BY to it.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
No is does not have an SQL query.
TomH
|
|
|
|
|
Any help out there???
Thanks
TomH
TomH
|
|
|
|
|
Any help out there?
Thanks.
TomH
TomH
|
|
|
|
|
Hey all,
I need a little help with printing. I have it all ready to print and it print fines, but I coded it stupidly. I hard coded the coordinates of where the text is printed, so it only prints correctly on certain printers, on others it prints all messed up. So now I am trying to change it so that it works right with all printers. This is what I have done so far.
<br />
<br />
CPrintDialog dlg(FALSE); <br />
CDC dc; <br />
#if 0 <br />
if (dlg.DoModal() == IDCANCEL) <br />
return; <br />
dc.Attach(dlg.GetPrinterDC());<br />
#else <br />
PRINTDLG prtDlg; <br />
AfxGetApp()->GetPrinterDeviceDefaults(&prtDlg); <br />
dlg.m_pd.hDevMode = prtDlg.hDevMode; <br />
dlg.m_pd.hDevNames = prtDlg.hDevNames; <br />
dc.Attach(dlg.CreatePrinterDC());<br />
#endif <br />
dc.m_bPrinting = TRUE; <br />
<br />
<br />
CRect printArea;<br />
printArea.SetRect(printArea.left/2, printArea.top/2, dc.GetDeviceCaps(HORZRES), dc.GetDeviceCaps(VERTRES));<br />
<br />
CString str("Delayed Entry");<br />
dc.DrawText(str, printArea, DT_NOPREFIX | DT_WORDBREAK);<br />
<br />
When I try that out it compiles fine, but when I print it it doesn't work, can anyone help me out here?
Thanks
|
|
|
|
|
Eversman wrote:
...it doesn't work, can anyone help me out here?
What doesn't work? What is the code (not) doing? What are you wanting it to do? Be a little more specific instead of just "it doesn't work" and you'll get much more help.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Well it doesn't print, it prints the old stuff that I had hard coded in, but when I change it to the new way I just showed, it doesn't print, well maybe it does but it would be off the page when it printed.
I am not sure if I am using the GetDeviceCaps and that such correctly.
|
|
|
|
|
Eversman wrote:
CRect printArea;
printArea.SetRect(printArea.left/2, printArea.top/2, dc.GetDeviceCaps(HORZRES), dc.GetDeviceCaps(VERTRES));
This should raise a red flag. You have a variable printArea that has not been initialized/assigned a value, yet you are trying to use its left and top members. Is that intentional?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Well, I am using this example that I found in the printing section. This is what the tutorial has it as.
<br />
<br />
CRect rect;<br />
rect.left = (JRECT.Width() - size.cx)/2;<br />
rect.right = rect.left + size.cx;<br />
rect.top = (JRECT.Height() - size.cy)/2;<br />
rect.bottom = rect.top + size.cy;<br />
<br />
JDC.DrawText(str, &rect, DT_SINGLELINE);<br />
<br />
so I kinda modified it to fit what I already had. No where in the example that I see is that stuff initialized. But I need to initialize it to the printer page resolution right? So would I have to initialize it to HORZRES and VERTRES?
|
|
|
|
|
Eversman wrote:
No where in the example that I see is that stuff initialized.
You're kidding, right? Two-thirds of the lines you've shown are initializing variables. When DrawText() is called, rect has all the right numbers.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
During porting the VCF to osx I came across a distinction that Apples uses - the notion of a composited window, where a window is the popup window where all the child controls live. While I was debugging something on OSX I found that if a window was marked as being composited ALL the child controls used the same graphics device to paint on during their paint event.
So, while I don't know how Apple does this, I started to wonder about this on Win32. What would happen if you maintained a map of popup windows and bitmap hdc's such that for each popup window you had one in-memory bitmap DC that was the height/width of the popup window. When the window was resized so would the bitmap. Then, for all the child control drawing, they would draw onto a section of this main DC, and then just bitblt the relevant part back to the HDC passed in to the WM_PAINT.
This would give you:
- automatic double buffering without each control having to maintain a separate bitmap/memory dc
- the ability to draw "outside" the edges of your control, for example if you wanted a "glow" effect on the edges of your control this would make this possible.
- possibly more efficient transparency effects that because you are reusing the same DC to paint on.
I would be curious to hear what others think. Has this been done before? If so did it work very well? Am I totally out of my mind?
Cheers
Jim
¡El diablo está en mis pantalones! ¡Mire, mire!
Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)!
SELECT * FROM User WHERE Clue > 0
0 rows returned
|
|
|
|
|
Sounds interesting. The child controls would need to be either rewritten or subclasses to use the new DC as the WM_PAINT message doesn't include a DC. Other than that, I think it has potential. I guess you'd BitBlt() the memory DC to the screen when the parent processes the WM_PAINT message as the children are always drawn first.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
Yeah, I've seen that before too  . And it would be good if it worked, but as it says, some common controls check this parameter, not all. And Windows itself never sets the wParam parameter; the WM_PAINT documentation states that wParam is unused. I've always thought this lack of DC was a very bad oversight.
But still, it could be useful
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
You get a WM_PAINT so you call BeginPaint and get a PAINTSTRUCT which has a DC as its first field. This is where the drawing should occur.
|
|
|
|
|
Blake Miller wrote:
You get a WM_PAINT so you call BeginPaint and get a PAINTSTRUCT which has a DC as its first field. This is where the drawing should occur.
Yeah, but applications have no control over that. The DC is defined by Windows, and is not given in the WM_PAINT message.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi All,
I'm using a CListCtrl in a dialog, and I've noticed that when it has the focus, the tab key will not cause it to change the focus to the next control in the tab order. Does anyone know what's up w/ this?
Note that OnGetDlgCode() is returning DLGC_WANTALLKEYS because I want to capture the Enter key. When I remove DLGC_WANTALLKEYS, the tab key changes the focus like I'm expecting, but it's a problem because I need to capture the Enter key.
How can I have my cake, and eat it too?
Thanks!!!
|
|
|
|
|
Try to narrow the problem down a bit. Does it happen with all projects or just this one? If the latter, does it happen with all list controls or just one in particular?
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Thanks for the reply! It was happening in every instance where my List Control was using my CListCtrl derived class that returned DLGC_WANTALLKEYS from OnGetDlgCode().
I came up a fix for it tho, which was to manually set the focus to the next window in the z-order (z-order == tab order).
Here's what my fix looked like:
BOOL CListCtrlEx::PreTranslateMessage(MSG* pMsg)
{
if( pMsg->message == WM_KEYDOWN && pMsg->wParam == VK_TAB )
{
CWnd * pNext = GetWindow(GW_HWNDNEXT);
CWnd * pFirst = pNext ? NULL : ( pNext = GetWindow(GW_HWNDFIRST) );
while(pNext)
{
DWORD dwStyle = pNext->GetStyle();
if( dwStyle & WS_TABSTOP
&& pNext->IsWindowVisible()
&& pNext->IsWindowEnabled()
&& pNext->GetSafeHwnd() != m_hWnd )
{
pNext->SetFocus();
return FALSE;
}
pNext = pNext->GetWindow(GW_HWNDNEXT);
if( pNext == NULL && pFirst == NULL )
{
pNext = pFirst = GetWindow(GW_HWNDFIRST);
}
}
}
return CListCtrl::PreTranslateMessage(pMsg);
}
|
|
|
|
|
i want to dynamically create a tabctrl and add tabs dynamically to it. Also teh controls rendered on each tab will be dynamically created. Any suggestion of how it can be achieved.
|
|
|
|
|
i am successfully able to create the tabcontrol using the cdialog extended class as tabs. what is the difference in "can do and cannot do" if a property sheet is used instead? Which of the two is better to use and why?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
