Codejock Developer Community : [SOLVED] BUG: Strange edit control behaviour?

[SOLVED] BUG: Strange edit control behaviour? : Hi;I tried it and now it works...

Wed, 07 Jan 2009 09:25:49 +0000

Author: mgampi
Subject: 12975
Posted: 07 January 2009 at 9:25am

Hi;
I tried it and now it works as expected!
But I'm still insitent that a customizable edit control would be a requirement for the report control.

Thanks for you help!

[SOLVED] BUG: Strange edit control behaviour? : Hey, finally I make a control...

Sun, 04 Jan 2009 23:15:26 +0000

Author: mdoubson
Subject: 12975
Posted: 04 January 2009 at 11:15pm

Hey, finally I make a control which recover previous selection if OnEditChanging not commit. Please try it and keep me updated

void CXTPReportInplaceEdit::OnEnChange()

{

if (m_bSetWindowText || !pControl || !pItem)

return;

CString strValue, strValNew;

GetWindowText(strValue);

strValNew = strValue;

//recover previous selection by diff between old and new text - compare from the start and from the end

int kO = strValue.GetLength();

int kP = m_strText_prev.GetLength();

int K = min(kO, kP);

int kOld(0);

int kOldEnd(kP);

if (m_strText_prev != strValue)

{

for (int j = 0; j < K; j++)

{

if (m_strText_prev[j] != strValue[j])

{

kOld = j;

break;

}

for (int j = 1; j <= K; j++)

{

if (m_strText_prev[kP - j] != strValue[kO - j])

{

kOldEnd = kP + 1 - j;

break;

}

BOOL bCommit = pItem->OnEditChanging((XTP_REPORTRECORDITEM_ARGS*)this, strValNew);

//Test cases for Forum discussion (Topic: BUG: Strange edit control behaviour? - 19 December 2008)

//test case for key entry rejected by OnEditChanging handler

//int iRep1 = strValNew.Replace("#", "@");

//int iRep2 = strValNew.Replace("?", "");

//if (iRep1 > 0 || iRep2 > 0)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for paste operation rejected by OnEditChanging handler

//if (strValNew.Find("666666") > - 1)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for Forum discussion

if (!bCommit || strValNew != strValue)

{

int nSelStart = 0, nSelEnd = 0;

GetSel(nSelStart, nSelEnd);

int kN = strValNew.GetLength();

int kk = min(kO, kN);

if (strValNew != strValue) //it means that bCommit is TRUE

{

SetWindowText(strValNew);

int k(kk - 1);

for (int j = 0; j < kk; j++)

{

if (strValNew[j] != strValue[j])

{

k = j;

break;

}

SetSel(k, k);

}

else //it means that bCommit is FALSE - need rollback

{

SetWindowText(m_strText_prev);

SetSel(kOld, kOldEnd);

if (nSelStart == kO && nSelEnd == kO && kP < kO)

SetSel(nSelStart, nSelEnd);

if (nSelStart == 1 && nSelEnd == 1 && kP < kO)

SetSel(0, 0);

}

else

{

m_strText_prev = strValue;

//Normal (default) cursor positioning

}

[SOLVED] BUG: Strange edit control behaviour? : >>the whole selection is...

Fri, 02 Jan 2009 18:18:57 +0000

Author: mdoubson
Subject: 12975
Posted: 02 January 2009 at 6:18pm

>>the whole selection is cleared and the cursor is moved to the beginning of the text

btw - this is a standard reaction - e.g. C# System.Windows.Forms.MaskedTextBox()

if you select previous (validated) value and paste smth wrong - all selection clear and value set to default (initial - e.g. empty or prompt)

[SOLVED] BUG: Strange edit control behaviour? : mdoubson wrote:Well - let's...

Fri, 02 Jan 2009 13:59:27 +0000

Author: mgampi
Subject: 12975
Posted: 02 January 2009 at 1:59pm

mdoubson wrote:

Well - let's extend the concept to cover your copy operation

Now we have different reactions for test case. Suppose your validation reject the string modification when string has "666666" pattern. It means that for key by key entry validation will allow to input "66666" and will stop on next "6" BUT if user PASTE "666666" as one Ctrl+V operation - all operation will rejected. This is that updated case covered. Try and give me your feedback

void CXTPReportInplaceEdit::OnEnChange()

{

if (m_bSetWindowText || !pControl || !pItem)

return;

CString strValue, strValNew;

GetWindowText(strValue);

strValNew = strValue;

int kOld(0);

if (m_strText_prev != strValue)

{

for (int j = 0; j < min(strValue.GetLength(), m_strText_prev.GetLength()); j++)

{

if (m_strText_prev[j] != strValue[j])

{

kOld = j;

break;

}

BOOL bCommit = pItem->OnEditChanging((XTP_REPORTRECORDITEM_ARGS*)this, strValNew);

//Test cases for Forum discussion (Topic: BUG: Strange edit control behaviour? - 19 December 2008)

//test case for key entry rejected by OnEditChanging handler

//int iRep1 = strValNew.Replace("#", "@");

//int iRep2 = strValNew.Replace("?", "");

//if (iRep1 > 0 || iRep2 > 0)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for paste operation rejected by OnEditChanging handler

//if (strValNew.Find("666666") > - 1)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for Forum discussion

if (!bCommit || strValNew != strValue)

{

int nSelStart = 0, nSelEnd = 0;

GetSel(nSelStart, nSelEnd);

//test case for Forum discussion

if (strValNew != strValue) //it means that bCommit is TRUE

{

SetWindowText(strValNew);

int k(0);

for (int j = 0; j < min(strValue.GetLength(), strValNew.GetLength()); j++)

{

if (strValNew[j] != strValue[j])

{

k = j;

break;

}

SetSel(k, k);

}

else //it means that bCommit is FALSE - need rollback

{

SetWindowText(m_strText_prev);

//SetSel(nSelStart -1, nSelEnd - 1);

SetSel(kOld, kOld);

//Cursor position before 1st OnEditChanging - handler - modified symbol

}

//test case for Forum discussion

//MD - old code <<

// SetWindowText(bCommit ? strValNew : m_strText_prev);

// SetSel(nSelStart, nSelEnd);

//MD - old code >>

}

else

{

m_strText_prev = strValue;

//Normal (default) cursor positioning

}

Ok, I'll try it.

[SOLVED] BUG: Strange edit control behaviour? : mdoubson wrote:btw - why you...

Fri, 02 Jan 2009 12:50:59 +0000

Author: mgampi
Subject: 12975
Posted: 02 January 2009 at 12:50pm

mdoubson wrote:

btw - why you don't complain about non-supported Ctrl+A action?

You can modify OnChar function adding in the end few lines:

void CXTPReportInplaceEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)

{

...........................................

if (nChar == 1 && nFlags == 30) //Ctrl+A case

{

SetSel(0, -1);

}

CEdit::OnChar(nChar, nRepCnt, nFlags);

}

Hi;
As I told in one of my previous posts, our company guidelines do not allow to change regular toolkit code, to avoid additional work and possible 'hidden' failures when new toolkit releases are available. We're using the toolkit since version 2.x and in the past we had to fix several bugs that came from modifying the core toolkit source.
Today I dig into the CXTPReportRecordItem class to eventually find another solution for our editing issue, but until now with no success

[SOLVED] BUG: Strange edit control behaviour? : btw - why you don't complain...

Fri, 02 Jan 2009 12:24:55 +0000

Author: mdoubson
Subject: 12975
Posted: 02 January 2009 at 12:24pm

btw - why you don't complain about non-supported Ctrl+A action?

You can modify OnChar function adding in the end few lines:

void CXTPReportInplaceEdit::OnChar(UINT nChar, UINT nRepCnt, UINT nFlags)

{

...........................................

if (nChar == 1 && nFlags == 30) //Ctrl+A case

{

SetSel(0, -1);

}

CEdit::OnChar(nChar, nRepCnt, nFlags);

}

[SOLVED] BUG: Strange edit control behaviour? : Well - let's extend the concept...

Fri, 02 Jan 2009 11:37:05 +0000

Author: mdoubson
Subject: 12975
Posted: 02 January 2009 at 11:37am

Well - let's extend the concept to cover your copy operation

void CXTPReportInplaceEdit::OnEnChange()

{

if (m_bSetWindowText || !pControl || !pItem)

return;

CString strValue, strValNew;

GetWindowText(strValue);

strValNew = strValue;

int kOld(0);

if (m_strText_prev != strValue)

{

for (int j = 0; j < min(strValue.GetLength(), m_strText_prev.GetLength()); j++)

{

if (m_strText_prev[j] != strValue[j])

{

kOld = j;

break;

}

BOOL bCommit = pItem->OnEditChanging((XTP_REPORTRECORDITEM_ARGS*)this, strValNew);

//Test cases for Forum discussion (Topic: BUG: Strange edit control behaviour? - 19 December 2008)

//test case for key entry rejected by OnEditChanging handler

//int iRep1 = strValNew.Replace("#", "@");

//int iRep2 = strValNew.Replace("?", "");

//if (iRep1 > 0 || iRep2 > 0)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for paste operation rejected by OnEditChanging handler

//if (strValNew.Find("666666") > - 1)

//{

// bCommit = FALSE;

// strValNew = strValue;

//}

//test case for Forum discussion

if (!bCommit || strValNew != strValue)

{

int nSelStart = 0, nSelEnd = 0;

GetSel(nSelStart, nSelEnd);

//test case for Forum discussion

if (strValNew != strValue) //it means that bCommit is TRUE

{

SetWindowText(strValNew);

int k(0);

for (int j = 0; j < min(strValue.GetLength(), strValNew.GetLength()); j++)

{

if (strValNew[j] != strValue[j])

{

k = j;

break;

}

SetSel(k, k);

}

else //it means that bCommit is FALSE - need rollback

{

SetWindowText(m_strText_prev);

//SetSel(nSelStart -1, nSelEnd - 1);

SetSel(kOld, kOld);

//Cursor position before 1st OnEditChanging - handler - modified symbol

}

//test case for Forum discussion

//MD - old code <<

// SetWindowText(bCommit ? strValNew : m_strText_prev);

// SetSel(nSelStart, nSelEnd);

//MD - old code >>

}

else

{

m_strText_prev = strValue;

//Normal (default) cursor positioning

}

[SOLVED] BUG: Strange edit control behaviour? : Hi;I tried your solution and it...

Fri, 02 Jan 2009 08:44:05 +0000

Author: mgampi
Subject: 12975
Posted: 02 January 2009 at 8:44am

Hi;
I tried your solution and it partially works.
Two issues are not solved:

1. The user selects the whole text in the edit control and presses a key that is not accepted by the regex pattern. Then in your solution, the whole selection is cleared and the cursor is moved to the beginning of the text. This is also true for partially selected text. Other edit controls have a different behaviour: in this case, the edit control selection is kept the same.
(This was my first problem when implementing this 'custom' edit task).
2.

You wrote:

if (strValNew != strValue)
{
   SetWindowText(strValNew);
   int k(0);
   for (int j = 0; j < strValue.GetLength(); j++){
      if (strValNew[j] != strValue[j])

What if strValNew is shorter than strValue? Wouldn't this lead to access violations?

BTW: You didn't answer my question about custom edit controls in future releases...

[SOLVED] BUG: Strange edit control behaviour? : Ok!Do you have plans to enable...

Mon, 29 Dec 2008 17:28:31 +0000

Author: mgampi
Subject: 12975
Posted: 29 December 2008 at 5:28pm

Ok!
Do you have plans to enable custom inplace edit controls too?
We will need several mask edit control types in report controls of our software.

[SOLVED] BUG: Strange edit control behaviour? : Sure I will change the toolkit...

Mon, 29 Dec 2008 17:19:18 +0000

Author: mdoubson
Subject: 12975
Posted: 29 December 2008 at 5:19pm

Sure I will change the toolkit code. Try to test also the case you do smart validation and change smth inside your derived code - check how logical will be the resulted cursor position