project64/Source/Project64/UserInterface/WTLControls/EditNumber32.cpp

397 lines
9.3 KiB
C++
Raw Normal View History

#include "stdafx.h"
2022-09-21 05:16:07 +00:00
#include "EditNumber32.h"
CEditNumber32::CEditNumber32(void) :
m_DisplayType(DisplayDec)
{
}
CEditNumber32::~CEditNumber32(void)
{
}
bool CEditNumber32::IsHexConvertableText(LPTSTR _text)
{
int start, end;
GetSel(start, end);
std::string WindowText = GetCWindowText(*this);
bool bPaste = true;
size_t Len = WindowText.size();
char head = Len > 0 ? WindowText[0] : 0;
char second = Len > 1 ? WindowText[1] : 0;
if (second == 'X' || second == 'x')
{
if (end <= 1)
{
bPaste = false;
}
}
2022-09-26 02:31:54 +00:00
if (!bPaste)
{
return bPaste;
}
// Check
unsigned int i = 0;
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
unsigned int len = wcslen(_text);
if (len == 0)
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
return false;
}
wchar_t c;
do
{
c = _text[i];
if (c == L'\n' || c == L'\r' || c == L' ')
{
i++;
continue;
}
break;
} while (i < len);
if (i == len)
{
return false;
}
if ((len - i) >= 2)
{
if (_text[i] == L'0' && (_text[i + 1] == L'x' || _text[i + 1] == L'X'))
{
2020-05-12 12:19:05 +00:00
if ((second == L'x' || second == L'X') && (!(start == 0 && end >= 2)))
{
bPaste = false;
}
else if (start > 0)
{
bPaste = false;
}
else
{
i += 2;
}
}
}
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
if (!bPaste) return bPaste;
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
if ((len - i) >= 1)
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
bool bIsX = _text[i] == L'x' || _text[i] == L'X';
if (head == L'0' && bIsX)
{
i++;
}
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
if (bIsX)
{
2020-05-12 12:19:05 +00:00
if (head != L'0' && start == 0)
{
bPaste = false;
}
2020-05-12 12:19:05 +00:00
else if (!(start == 1 && end >= 1 && head == L'0'))
{
bPaste = false;
}
}
}
if (!bPaste) return bPaste;
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
for (; i < len; i++)
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
c = _text[i];
2022-09-21 05:16:07 +00:00
if (!(c >= 48 && c <= 57 || c >= L'A' && c <= L'F' || c >= L'a' && c <= L'f' || c == L' '))
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
if (c == L'\n' || c == L'\r')
{
i++;
while (i < len)
{
c = _text[i];
if (c != L'\n' && c != L'\r' && c != L' ')
{
bPaste = false;
break;
}
i++;
}
// Effectively a trim, if all we have is newline, just ignore them
break;
}
bPaste = false;
break;
}
}
return bPaste;
}
void CEditNumber32::FormatClipboard()
{
2022-09-21 05:16:07 +00:00
LPTSTR lptstr, lptstrCopy;
HGLOBAL hglb;
2020-06-14 08:04:41 +00:00
if (!this->OpenClipboard() || !IsClipboardFormatAvailable(CF_UNICODETEXT))
{
return;
}
2020-06-14 08:04:41 +00:00
hglb = GetClipboardData(CF_UNICODETEXT);
2021-04-12 11:35:39 +00:00
if (hglb != nullptr)
{
lptstr = (LPTSTR)GlobalLock(hglb);
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
unsigned int len = wcslen(lptstr);
unsigned int fullCopySize = 1; // Null terminator
for (unsigned int i = 0; i < len; i++)
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
wchar_t c = lptstr[i];
if (c != L' ' && c != L'\n' && c != L'\r')
{
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
fullCopySize++;
}
}
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
hglb = GlobalAlloc(GMEM_MOVEABLE, fullCopySize * sizeof(TCHAR));
2021-04-12 11:35:39 +00:00
if (hglb == nullptr)
{
CloseClipboard();
return;
}
lptstrCopy = (LPTSTR)GlobalLock(hglb);
Allowing a paste into a number field to be trimmed automatically (#2414) The specific issue I experienced is that Excel/LibreOffice Calc add a newline when you copy the contents of a single cell. This is bad behavior and they should provide a copy option that does not do that, but alas, it's much harder to get that into those applications. This behavior made it impossible to paste an otherwise-valid hex address into the Project64 fields without first putting it into Notepad, deleting the newline, recopying, and then doing the paste from there. If the field was simply text, you can go into the field edit and shift + home to select all and then do a copy, but that does not work for a formula. When you edit the file, it shows the formula instead. Therefore, you have absolutely no way of working around this except pasting it somewhere else and removing the newline manually. In principle, there's no reason why you wouldn't trim the ends at least. Whitespace on either end is useless to you. However, content being after the newline should be rejected as it was before. There were two secondary issues in the pasting code that are fixed here: One is that it only sort of collapsed single spaces. So if you had more than one space, spaces still would have ended up in the result. Actually I think the semantics were slightly more insidious, <space><number> would have turned into <number><same number> effectively. The only thing it did was remove the space by duplicating the number. If you had two spaces, then it would have ended up with e.g. <space><number><same number>. The only case where this wouldn't have happened is a space at the end which would have been preserved in the paste. Secondly, it mutated the clipboard data directly. This would have lead to confusing results where multiple pastes would have had clipboard data in the clipboard itself move from, for example, two spaces to a single space to no spaces at all. The better solution is to preprocess to figure out how big we ultimately want our space-less result to be and stamp out the copy ourselves skipping anything we don't want. Leave the clipboard alone. If it's desired to preserve single spaces only in the middle, the code will need to be modified a bit. Co-authored-by: Summate <summate.ssbm@gmail.com>
2024-06-06 04:52:26 +00:00
for (unsigned int src = 0, dst = 0; src < len; src++)
{
wchar_t c = lptstr[src];
if (c == L' ' || c == L'\n' || c == L'\r')
{
continue;
}
if (c == L'X' || c == L'x')
{
lptstrCopy[dst++] = L'x';
}
else
{
lptstrCopy[dst++] = (wchar_t)toupper(c);
}
}
GlobalUnlock(lptstr);
GlobalUnlock(hglb);
2020-06-14 08:04:41 +00:00
SetClipboardData(CF_UNICODETEXT, hglb);
CloseClipboard();
}
}
2022-09-21 05:16:07 +00:00
LRESULT CEditNumber32::OnValidateValue(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL & bHandled)
{
bHandled = true;
return true;
}
2022-09-21 05:16:07 +00:00
LRESULT CEditNumber32::OnPaste(UINT /*uMsg*/, WPARAM /*wParam*/, LPARAM /*lParam*/, BOOL & bHandled)
{
// Paste
bHandled = false;
2020-06-14 08:04:41 +00:00
if (!IsClipboardFormatAvailable(CF_UNICODETEXT))
{
bHandled = true;
return true;
}
if (!OpenClipboard())
{
bHandled = true;
return true;
}
2020-06-14 08:04:41 +00:00
HGLOBAL hglb = GetClipboardData(CF_UNICODETEXT);
2021-04-12 11:35:39 +00:00
if (hglb != nullptr)
{
2022-09-21 05:16:07 +00:00
LPTSTR lptstr = (LPTSTR)GlobalLock(hglb);
// Check invalid hex string
if (!IsHexConvertableText(lptstr))
{
bHandled = true;
}
GlobalUnlock(lptstr);
}
CloseClipboard();
if (!bHandled)
{
FormatClipboard();
}
return true;
}
2022-09-21 05:16:07 +00:00
LRESULT CEditNumber32::OnKeyDown(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL & bHandled)
{
int start, end;
GetSel(start, end);
std::string WindowText = GetCWindowText(*this);
char Head = WindowText.length() > 0 ? WindowText[0] : 0;
char Second = WindowText.length() > 1 ? WindowText[1] : 0;
if (uMsg == WM_CHAR)
{
size_t MaxLen = 30;
if (m_DisplayType == DisplayHex)
{
MaxLen = 8;
if (Second == L'x' || Second == L'X')
{
MaxLen += 2;
}
}
2020-05-12 12:19:05 +00:00
wchar_t c = (wchar_t)wParam;
if (wParam < 32)
{
if (wParam == 8 && (Second == 'x' || Second == 'X') && Head == '0' && end == 1)
{
// Does not allow to delete '0' before x
bHandled = true;
}
2022-09-21 05:16:07 +00:00
else
{
bHandled = false;
}
return TRUE;
}
if (Second == 'x' || Second == 'X')
{
// Does not allow to change head except select includes first and second
if (start <= 1 && end <= 1)
{
bHandled = true;
return TRUE;
}
}
if (start == 1 && (c == 'X' || c == 'x') && Head == '0')
{
if (c == 'X')
{
2020-05-12 12:19:05 +00:00
SendMessage(uMsg, L'x', lParam);
bHandled = true;
}
2022-09-21 05:16:07 +00:00
else
{
bHandled = false;
}
return true;
}
2020-05-12 12:19:05 +00:00
else if (c >= L'0' && c <= L'9' || c >= L'A' && c <= L'F')
{
if (WindowText.length() >= MaxLen && start == end)
{
bHandled = true;
return true;
}
bHandled = false;
return true;
}
2020-05-12 12:19:05 +00:00
else if (c >= L'a' && c <= L'f')
{
if (WindowText.length() >= MaxLen && start == end)
{
bHandled = true;
return true;
}
SendMessage(uMsg, wParam - 32, lParam);
bHandled = true;
return true;
}
bHandled = true;
return true;
}
bHandled = false;
return false;
}
BOOL CEditNumber32::Attach(HWND hWndNew)
{
return SubclassWindow(hWndNew);
}
BOOL CEditNumber32::AttachToDlgItem(HWND parent, UINT dlgID)
{
return SubclassWindow(::GetDlgItem(parent, dlgID));
}
void CEditNumber32::SetDisplayType(DisplayType Type)
{
DWORD lCurrentValue = GetValue();
m_DisplayType = Type;
SetValue(lCurrentValue);
}
uint32_t CEditNumber32::GetValue(void)
{
std::string Text = GetCWindowText(*this);
if (m_DisplayType == DisplayDec)
{
return atoi(Text.c_str());
}
size_t Finish = Text.length();
wchar_t Second = Finish > 1 ? Text[1] : 0;
size_t Start = (Second == 'x' || Second == 'X') ? 2 : 0;
2022-09-26 02:31:54 +00:00
if (Finish > 8 + Start)
{
Finish = 8 + Start;
}
DWORD Value = 0;
for (size_t i = Start; i < Finish; i++)
{
Value = (Value << 4);
switch (Text[i])
{
case '0': break;
case '1': Value += 1; break;
case '2': Value += 2; break;
case '3': Value += 3; break;
case '4': Value += 4; break;
case '5': Value += 5; break;
case '6': Value += 6; break;
case '7': Value += 7; break;
case '8': Value += 8; break;
case '9': Value += 9; break;
case 'A': Value += 10; break;
case 'a': Value += 10; break;
case 'B': Value += 11; break;
case 'b': Value += 11; break;
case 'C': Value += 12; break;
case 'c': Value += 12; break;
case 'D': Value += 13; break;
case 'd': Value += 13; break;
case 'E': Value += 14; break;
case 'e': Value += 14; break;
case 'F': Value += 15; break;
case 'f': Value += 15; break;
default:
Value = (Value >> 4);
i = Finish;
}
}
return Value;
}
void CEditNumber32::SetValue(uint32_t Value, DisplayMode Display)
{
2020-05-12 12:19:05 +00:00
stdstr text;
if (m_DisplayType == DisplayDec)
{
2020-05-12 12:19:05 +00:00
text.Format("%d", Value);
}
else
{
2022-09-21 05:16:07 +00:00
text.Format("%s%0*X", (Display & DisplayMode::ShowHexIdent) == DisplayMode::ShowHexIdent ? "0x" : "", (Display & DisplayMode::ZeroExtend) == DisplayMode::ZeroExtend ? 8 : 0, Value);
}
2020-05-12 12:19:05 +00:00
SetWindowText(text.ToUTF16().c_str());
}