Тотальная неудачница и убийца жёстких дисков.
#post-id: 7995-02-43
#original-date: 16.06.2022 Thu
#original-time: 2:43 AM
#original-day: 7995
#original-host: WinXP Home SP3 (Build 2600)
Бывает, выделишь в Экселе ячейки, скопируешь, потом по какой-то причине сбросишь выделение, пытаешься вставить ранее скопированное, а оно не вставляется, буфер обмена пуст. Вот этот пост немного поясняет, почему так:
https://devblogs.microsoft.com/oldnewthing/20220608-00/?p=106727
#upd(16.06.2022 - 2:47 AM):
The original customer problem was extracting a large range of cells, and their solution was to launch Excel, programmatically select a bunch of cells, and then copy them to the clipboard, so that another program could copy them out.
If you look at it, you’ll realize that this is using a global solution to a local problem. This automated process is using the shared clipboard as a way to transfer data between processes, which means that it will damage whatever was on the clipboard previously. And the user can’t use the clipboard while this automated process is running.
My guess is that the automated process is running on a dedicated computer with no interactive user present, so these problems are deemed inconsequential. But it also means that you want to run two copies of this automation, you need two computers!
https://devblogs.microsoft.com/oldnewthing/20220610-00/?p=106737
Well, that escalated quickly.
#upd(16.06.2022 - 2:49 AM):
Bonus chatter: I suspect their system came together when somebody wanted to automate a tedious business process and cobbled together something that “worked on my machine”, back when the spreadsheet was relatively small, like, maybe a few thousand rows. This lunch-hour hack became popular and eventually became part of the company’s critical workflow. Now that the spreadsheet has grown from a few thousand rows to hundreds of thousands of rows, the “quick and dirty hack” doesn’t quite hold up, and the customer will have to invest in a solution that has better scalability.
https://devblogs.microsoft.com/oldnewthing/20220610-00/?p=106737
Кажется, по этому принципу пишется половина госсофта. Особенно вот эта вот часть про появление проблем с ростом количества данных. Обычно это бывает так: внедряется новая прога, всё работает хорошо, потом народ начинает активно вносить данные, данных оказывается сильно больше, чем у разработчиков в тестовой среде, и прокрутка на один экран начинает занимать десять минут. /* А виноваты в итоге местные одмины, потому что пользователи позвонили в соответствующую контору, а там сказали обращаться к «своим программистам». */
#original-date: 16.06.2022 Thu
#original-time: 2:43 AM
#original-day: 7995
#original-host: WinXP Home SP3 (Build 2600)
Бывает, выделишь в Экселе ячейки, скопируешь, потом по какой-то причине сбросишь выделение, пытаешься вставить ранее скопированное, а оно не вставляется, буфер обмена пуст. Вот этот пост немного поясняет, почему так:
https://devblogs.microsoft.com/oldnewthing/20220608-00/?p=106727
#upd(16.06.2022 - 2:47 AM):
The original customer problem was extracting a large range of cells, and their solution was to launch Excel, programmatically select a bunch of cells, and then copy them to the clipboard, so that another program could copy them out.
If you look at it, you’ll realize that this is using a global solution to a local problem. This automated process is using the shared clipboard as a way to transfer data between processes, which means that it will damage whatever was on the clipboard previously. And the user can’t use the clipboard while this automated process is running.
My guess is that the automated process is running on a dedicated computer with no interactive user present, so these problems are deemed inconsequential. But it also means that you want to run two copies of this automation, you need two computers!
https://devblogs.microsoft.com/oldnewthing/20220610-00/?p=106737
Well, that escalated quickly.
#upd(16.06.2022 - 2:49 AM):
Bonus chatter: I suspect their system came together when somebody wanted to automate a tedious business process and cobbled together something that “worked on my machine”, back when the spreadsheet was relatively small, like, maybe a few thousand rows. This lunch-hour hack became popular and eventually became part of the company’s critical workflow. Now that the spreadsheet has grown from a few thousand rows to hundreds of thousands of rows, the “quick and dirty hack” doesn’t quite hold up, and the customer will have to invest in a solution that has better scalability.
https://devblogs.microsoft.com/oldnewthing/20220610-00/?p=106737
Кажется, по этому принципу пишется половина госсофта. Особенно вот эта вот часть про появление проблем с ростом количества данных. Обычно это бывает так: внедряется новая прога, всё работает хорошо, потом народ начинает активно вносить данные, данных оказывается сильно больше, чем у разработчиков в тестовой среде, и прокрутка на один экран начинает занимать десять минут. /* А виноваты в итоге местные одмины, потому что пользователи позвонили в соответствующую контору, а там сказали обращаться к «своим программистам». */