|
Hi ehaerim
The problem might indeed be that the files should be saved as Unicode - this has helped people with certain Ultimate Toolbox files - see this[^] thread.
If you've installed the Ultimate Toolbox files, you could try compiling the ParserView sample located in the samples/utility/Parser directory. The files OXQuickString.cpp, OXPhysicalEditEx.cpp, OXParser.cpp, and OXHTMLParser.cpp will probably need to be saved as Unicode for this to compile on your system.
I'd like to know more about your system - whether it is running a Korean Windows version, and any other info you can provide on the regional settings - also, your compiler version and resource culture settings.
It may be that we should be providing Unicode source - but this is the first report of this many warnings I've seen with the Ultimate Grid, and would like to see if some other quirk involved.
Any info appreciated.
Thanks
Tim
|
|
|
|
|
[1] The cause of numerous warnings is the copyright character.
I had to change the copyright character ( 'c' in a circle whose ASCII code is A9) into (C) to remove all the numerous warnings.
Why don't you replace the copyright character with (C) to avoid these warnings?
[2] I get the following warning. Could you replace it with the recommended mbstowcs_s?
1>UTEdit.cpp
1>..\EditControls\UTEdit.cpp(1884) : warning C4996: 'mbstowcs': This function or variable may be unsafe. Consider using mbstowcs_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1> C:\Program Files\Microsoft Visual Studio 8\VC\include\stdlib.h(537) : see declaration of 'mbstowcs'
|
|
|
|
|
When compiling, I got the following errors:
c:\download\ultimategrid\ultimate grid\demos\outlookstyle\stdafx.h(25) : fatal error C1083: Cannot open include file: 'OXAdvancedAssert.h': No such file or directory
c:\download\ultimategrid\ultimate grid\datasources\ado\adoimpdatasource.cpp(36) : error C2001: newline in constant
CADOImpDatasource::CADOImpDatasource()
{
...
m_sCurRowID = _T("?); // => quote is not closed and i am not sure what value this should be.
contextsensitivegrid.hpj
HC5011: Error: contextsensitivegrid.hpj :
Cannot open the file "D:\Program Files\Microsoft Visual Studio\VC98\MFC\Include\AFXHELP.HM."
|
|
|
|
|
Hi ehaerim
ehaerim wrote: c:\download\ultimategrid\ultimate grid\demos\outlookstyle\stdafx.h(25) : fatal error C1083: Cannot open include file: 'OXAdvancedAssert.h': No such file or directory
This project is a mess - yikes - QA will be notified. The code shipped uses a lot of the Ultimate Toolbox files, and to make matters worse the paths in the project file are incorrect, referencing a UTB 92 dir. It also includes the cryptograpy files, which are not needed and can be removed (these aren't included in the source download for UT).
It does work with the corrections though - if you email me (tim_at_codeproject.com) I can update you - currently have a VS2005 project working, but can fix the VC6 if you need it. Should probably put this on the updates page.
ehaerim wrote: m_sCurRowID = _T("?); // => quote is not closed and i am not sure what value this should be.
There was an extended ascii 175 character there - like a double greater than - you're machine may have regional language settings that don't recognize it - probably not a good idea to use that char - (I think it's intended as a current row indicator for the side heading).
Try:
m_sCurRowID = _T(">");
ehaerim wrote: Cannot open the file "D:\Program Files\Microsoft Visual Studio\VC98\MFC\Include\AFXHELP.HM."
I think the problem here is that the help project file hard codes the path to this file - you should be able to correct this by opening the .hpj and editing the line near the bottom of the file to reflect your VC include path:
#include <ContextSensitiveGrid.hm>
#include D:\Program Files\Microsoft Visual Studio\VC98\MFC\Include\AFXHELP.HM
#include TopicsDefines.h
Tim
|
|
|
|
|
Hi Tim,
I just implemented an autofilter functionality in my UG based grid. It works perfectly, however when the droplist contains more than three items (but not enough to show a scrollbar), it always shows one or more white, unselectable, rows at the bottom. I'm using the standard UG fonts (I believe it is arial).
Do you have any idea if we can get rid of this white rows at the bottom? Or is this also solved in 7.2?
Thanks,
Gerbrand
|
|
|
|
|
Sounds like an extra new line in the label text - doing this:
cell.SetLabelText(_T("One\nTwo\nThree\n\n"));
will show an extra line.
Don't think it's a version issue.
The v7.2 changes are for the most part minor fixups - shouldn't be any issues integrating unless you've modified the source.
Cheers
Tim
|
|
|
|
|
Hi Tim,
Sorry for the late respons (holiday time). I have had some time now to give it another look, and I'm very positive that the text does not end on a double '\n'. Do you need any other info?
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?
With kind regards,
Gerbrand
|
|
|
|
|
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.
|
|
|
|
|