|
G12345678 wrote: and I'm very positive that the text does not end on a double '\n'. Do you need any other info?
Well, you could check the code in OnGetCell for any manipulation of the label text, or possibly check for strings set to the column defaults.
G12345678 wrote: One other thing I noticed what if a complete row consists of drop down list cells, and I press one cell, visually all cells are 'pressed'. The list itself only appears in the cell which is actually pressed. Any thoughts about this?
Most odd - can you tell me what sort of window the grid is on, and maybe send some of your setup code? Multiselect, RowHighlight, that sort of thing. I'll have another shot at reproducing it - or, if you can put together a small demo (tim_at_codeproject.com) that's good too - I can test with both 7.1 and 7.2.
Tim
|
|
|
|
|
Well, you could check the code in OnGetCell for any manipulation of the label text, or possibly check for strings set to the column defaults.
I'm quite sure that the label is not manipulated. I debugged it into the UGDLType.cpp. The list.GetCount returns the correct amount of items, however, in certain circumstances I see one or two extra white, not selectable, lines. If the count is equal to 8, I get one extra line. If the count is 13, I get two extra lines. If it is larger than 15, I do not get any extra lines (but a scrollbar). Also, if the count is 3, I got no extra lines. The font used is MS Sans Serif.
[EDIT] I now tracked it into the UGDLType. Apparently, the MS Sans Serif has a corrected height of 15 (result of -MulDiv). If I override this with 14 (or even 13), all listboxes look correct (no blank lines). Can it be a rounding error? On MSDN, I found the following page: http://support.microsoft.com/kb/110764[^]. Seems to be the same as my problem... I have not yet tried different fonts.
[END OF EDIT]
[EDIT2]
I think I have solved this issue. When determining the height to be used (UGDLType.cpp, function StartDropList), the point size was not taken into consideration. I now changed it into the following code:
HDC hDC = CreateCompatibleDC(NULL);
long nPtSize;
TEXTMETRIC tm;
GetTextMetrics(hDC, &tm);
nPtSize = -MulDiv(tm.tmHeight - tm.tmInternalLeading, 72, GetDeviceCaps(hDC, LOGPIXELSY));
lf.lfHeight = -MulDiv(nPtSize, GetDeviceCaps(hDC, LOGPIXELSY), 72);
DeleteDC(hDC);
This works as supposed to: no more blank lines. Do you agree, or do you have a different solution?
[END of EDIT2]
Most odd - can you tell me what sort of window the grid is on, and maybe send some of your setup code? Multiselect, RowHighlight, that sort of thing. I'll have another shot at reproducing it - or, if you can put together a small demo (tim_at_codeproject.com) that's good too - I can test with both 7.1 and 7.2.
Multiselect is false, and RowHighlight is true. I tried it with rowhighlight to false, and that works, so it seems to be caused by the rowhighlight. I not yet debugged it into the drawing of the cell, but when I find some time, I will do that.
[EDIT3]
Did another change in the UGDLType.cpp, which seems to have solved above issue. This time in the function OnDraw. I now have the following code to draw the 3D Buttons:
if(m_btnDown && current && col == m_btnCol){
cell->SetBorder(UG_BDR_RECESSED);
DrawBorder(dc,rect,&rectout,cell);
}
else{
cell->SetBorder(UG_BDR_RAISED);
DrawBorder(dc,rect,&rectout,cell);
}
However, I'm not quite sure if this will work in all circumstances (it seems to though). What is your thought?
[END OF EDIT3]
When I have any other info, I will let you know. If you have any questions, just ask.
Thanks in advance,
Gerbrand
modified on Tuesday, August 26, 2008 10:31 AM
|
|
|
|
|
Thanks Gerbrand
I've bookmarked this as update material - these changes look good, and are not in v7.2. I think I can work with what you've posted here and test.
Thanks again, nice work.
Tim
|
|
|
|
|
Hi Gerbrand
I did some testing of the font height code, and I'm not sure it's the best all round solution. I feel that I'm missing something in the calculation - when I get it right for one font/number of items, it fouls up on another.
Your changes do make a difference in getting rid of the blank lines, but they will often result in a rect that requires a scroll bar. The behavior that was intended was that if there is room on the grid window, the list can expand to show up to 15 items without scrolling. With your changes (if I have them correctly) many combinations of font sizes and number of items will result in a window that's one or two lines too short, requiring a scroll, even though there is lots more room to show all items without one. This is not necessarily a problem for you with your changes, but I hesitate to change the default behavior.
There may be something fundmentally wrong with the approach - maybe an owner draw list would be better - or it may just need a small adjustment based on the number of items (that hardcoded + 6 at the point at which rect.bottom is adjusted is suspicious).
Two other points -
1. It seems better to attach a CDC to the current DC and select the font into that to get the textmetrics. But even with that I wasn't able to get things right for all combinations.
2. There is a call to MoveWindow after the list is created - if that call is commented out, you'll probably see results similar to your own changes (with maybe less situations that truncate the rect). I think the call to Create is adjusting the rect - but not sure how/why, since it has no items yet. Which leads me to believe the '15 item no-scroll' spec may just be tricky to implement.
Anyway, I'm confused, and have that feeling I get when I'm missing something obvious. Seems to happen more often with age...
Tim
|
|
|
|
|
Hi Tim,
I took another look at this issue, and also come to the conclusion that my solution might be a bit restrictive. Not all combinations of fonts and sizes are covered with this, as you have already figured out.
It took me some puzzle time, but I have come up with a different solution, which seems to work in all cases, although it might not the 'most beautiful' solution:
Between the statements m_listBox->SetFont(font) and m_listBox->MoveWindow(&rect,FALSE), I added the following piece of code:
itHeight = m_listBox->GetItemHeight(0);
if (len > 15)
len = 15;
rect.bottom = rect.top + len * itHeight + 6;
if(rect.bottom > clientRect.bottom){
dif = rect.bottom - clientRect.bottom;
rect.bottom -= dif;
rect.top -= dif;
if(rect.top <0)
rect.top = 0;
}
if(rect.right > clientRect.right){
dif = rect.right - clientRect.right;
rect.right -= dif;
rect.left -= dif;
if(rect.left <0)
rect.left = 0;
}
Of course, the rectangle determination before creating the window can now be deleted, although you should have a default rect (which I kept the m_ctrl->GetCellRect(m_btnCol,m_btnRow,&rect) ).
The '+ 6' is necessary to prevent rounding errors, as far as I have figured it out.
What are your thoughts about this?
Thanks,
Gerbrand
|
|
|
|
|
Yes - I think you've got it - nice!
I'll tag this for inclusion in the next update - with some cleanup, as you mentioned.
Thanks again,
Tim
|
|
|
|
|
Hi there,
I had a project working with VS6 using UG71. Part of this project is copying a selection of cells to the clipboard (through CopySelected). This worked well, and I used it to, for example, Paste the contents in Excel. However, after using VS 2008, this no longer works. It now crashes in the UGStrOp.cpp (called from CopyToClipboard):
void UGStr::tcscpy(TCHAR * dest, SIZE_T length, const TCHAR* src)
{
#if _MSC_VER >= 1400
::_tcscpy_s(dest, length, src);
#else
UNREFERENCED_PARAMETER(length);
::_tcscpy(dest,src);
# endif
}
Does anyone have a solution for this (besides using VS6 again...)?
Thanks,
Gerbrand
|
|
|
|
|
Hi
Tried a quick test in VS2008 and seems ok.
Any more info on the nature of the crash and what's getting passed in here?
Also interested to know if you are using v7.2 now, and what setup you might re SetHighlightRow and SetMultiSelectMode . I'm wondering if there could be a null item passed in as a result of a copy of a row based selection or some such.
Tim
|
|
|
|
|
Hi Tim,
Some more information about the crash (assert) I'm experiencing:
I have a single cell selected, with data '5372'.
In UGStrOp.cpp, the following line is executed:
::_tcscpy_s(dest, length, src);
with dest empty but allocated, length = 4 en src = "5372".
Next, it appears that the buffer (destination) is not large enough, as the next function returns " _RETURN_BUFFER_TOO_SMALL(_DEST, _SIZE);" However, the destination is the global clipboard. And it appears to be correctly allocated (with the correct size, in this case 4 + 1). So at this moment I do not really have a clue on what is wrong.
Wkr,
Gerbrand
|
|
|
|
|
I think you should have a value of 5 for len entering that call - check the calc of len in CopyToClipBoard :
int CUGCtrl::CopyToClipBoard(CString* string){
int len;
OpenClipboard();
EmptyClipboard();
len = (string->GetLength()+1) * sizeof(TCHAR);
...
There were some '+1' fixups in this area iirc - if you're running non-unicode, len should be passed in directly - if Unicode, the code should be
UGStr::tcscpy(stringu, ::wcslen(*string)+1, (LPCWSTR)*string);
Again, one more than the string length. Sounds like you might be using 7.1 code (?) - (btw VC 6 would ingnore the length and call the non-safe version of _tcscpy, which is probably why v7.1 was ok up to now).
Tim
|
|
|
|
|
Hi Tim,
Indeed, as I mentioned in my first version, I'm using the 7.1 code. Before 7.1, we were still using the 3.0 code. About two years ago, we decided to upgrade, and at that time, we still had to buy the source. As it was a rather large upgrade (from 3.0 to 7.1), I did not yet spent any time in upgrading it to 7.2 (also because 7.1 was working perfectly with VS 6). But this might be the right time to upgrade to the next version...
Wkr,
Gerbrand
|
|
|
|
|
Hi, how can I use multiline hints?
I have my hints working now normally, but when i try to put \n in the string, it shows as a box in hint, and it doesn't make a new line?
|
|
|
|
|
Hi,
You can try using \r\n instead of just \n. I never tried it on multiline hints, but it at least works in a multiline edit control.
Wkr,
Gerbrand
|
|
|
|
|
It didn't help, it just shows 2 boxes now, yes, it does work with editbox, but not in hint.
|
|
|
|
|
|
This code in uggrid.cpp (line 140 - CUGGrid::ToolTipNeedText ) allows multiline:
if ( m_ctrl->GetCellFromPoint( point.x, point.y, &col, &row ) == UG_SUCCESS )
{
if ( m_ctrl->OnHint( col, row, UG_GRID, &string ) == TRUE )
{
TOOLTIPTEXT *pTTT = (TOOLTIPTEXT *)pTTTStruct;
::SendMessage( pTTT->hdr.hwndFrom, TTM_SETMAXTIPWIDTH, 0, SHRT_MAX );
::SendMessage( pTTT->hdr.hwndFrom, TTM_SETDELAYTIME, TTDT_AUTOPOP, SHRT_MAX );
::SendMessage( pTTT->hdr.hwndFrom, TTM_SETDELAYTIME, TTDT_INITIAL, 200 );
::SendMessage( pTTT->hdr.hwndFrom, TTM_SETDELAYTIME, TTDT_RESHOW, 200 );
pTTT->lpszText = const_cast<LPTSTR>((LPCTSTR)string);
return TRUE;
}
}
return FALSE;
The grid and corner buttons should have this - the side and topheadings don't.
If you are displaying tooltips in the grid or corner button, the call above to TTM_SETMAXTIPWIDTH will correct the problem once a tooltip is displayed in these areas - if not, you'll see no character (and no line break) in a Unicode app, and the box char in non-unicode for tooltips in the top and side headings.
So G12345678 is right - you could possibly more efficiently use his suggestion, or add the code above to the corresponding functions in the top and side heading classes.
Tim
|
|
|
|
|
Gee, thanks, I got it working now.
|
|
|
|
|
ToggleCell appears to be the only method in the vanilla UG that actually implements the concept of deselection. That is, it is the only method that sets selected=FALSE in the entries in the lists of selection blocks. However, ToggleCell is not actually called from anywhere in the UG code (as stated in the prologue comments to the method). This fact, together with the undocumented UG_MULTISELECT_NODESELECT mode, gives me the impression that the concept of 'deselecting' still has some rough edges.
The problems I have encountered are:
1. The selection-block search logic of ToggleCell does not match the logic of IsSelected. ToggleCell will toggle the first single-cell selection block that matches the specified (col,row), while IsSelected reports the selection state of the last selection block that contains (col,row). Thus if you alternately call ToggleCell and CUGCtrl::Select (which adds a new block every time) on the same (col,row) they quickly become inconsistent.
2. IsCellInColSelected and IsCellInRowSelected do not deal with deselection properly – if a deselected block (i.e. cell) is the last entry in the list that has the specified col/row, they return false, even if earlier blocks crossing that col/row actually are selected.
The first point could be addressed by having ToggleCell always append a new block with 'selected' set appropriately, rather than toggle an existing block. This would be consistent with CUGCtrl::Select and the general idea that 'last matching selection block wins' when determing cell selection state.
The second point is more problematic as a consistent solution would require tracking the part-blocks that intersect the given row/col and determining whether their cumulative effect is to leave at least one cell selected. Perhaps it would be safer and simpler to always break the search when a selected cell is found, ignoring the fact that a later block might deselect it. Since neither of these methods are called by the UG code, it might be sufficient to add a comment to state that they are not safe to use in conjunction with ToggleCell.
If I get the time, I might try out these ideas by overriding the relevant methods in a class dervied from CUGMultiSelect.
Has anybody else got deselection working reliably? I would be interested to know.
|
|
|
|
|
Perhaps ToggleCell should be removed from the next release. It sounds like it doesn't work very well.
|
|
|
|
|
I can align the checkbox text but I want no text and the checkbox centered in the cell. Is this possible?
Dave Winsett
|
|
|
|
|
Yes
Add the UGCT_CHECKBOXUSEALIGN extended style to the checkbox (SetCellTypeEx):
UGCT_CHECKBOXUSEALIGN - use this style to allow the check box
to respect the alignment set to a cell.
Please note that when this style is set
then the check box will not draw the text
assigned to a cell.
Then set the alignment of the cell to UG_ALIGNCENTER - should do it.
Tim
|
|
|
|
|
hi tim
When I open a empty table from a *.mdb file in a grid the error3021 is showed to me . I want delete it and this error doesn't handle.
plz help,
thanks;
|
|
|
|
|
Hi Vahid
Just did a quick test and I can open an empty table in both of the DAO datasource samples in the DataSources\DAO dir and the DaoDlg project in the Examples directory - is this error occuring as you delete rows?
Tim
|
|
|
|
|
Hi,
I want to place a CUGButtonType in the top corner of my grid, but I failed. I want to use this button for some reset functionality of my grid.
Of course I can use the OnCB_LClicked override, but I'm missing the typical push button behavior.
...
|
|
|
|
|
The lclick is not passed to the celltype for the corner button.
One blatant hack work around:
void MyCug::OnCB_LClicked(int updn,RECT *rect,POINT *point,BOOL processed)
{
UNREFERENCED_PARAMETER(*point);
UNREFERENCED_PARAMETER(processed);
if(updn) {
QuickSetBorder(-1,-1,UG_BDR_RECESSED);
InvalidateRect( rect, 0);
SendMessage( WM_PAINT, 0, 0);
Sleep(200);
QuickSetBorder(-1,-1,UG_BDR_RAISED);
InvalidateRect( rect, 0);
SendMessage( WM_PAINT, 0, 0);
}
} This bypasses the type of mouse move tracking that a real button would use to reset itself when the mouse is moved off the rect before the button is released, forcing you to respond on the down click.
Not ideal - might be passable if a confirmation mb shown - dunno.
Better handling of celltypes in headers has long been on the wish list.
Tim
|
|
|
|
|