|
I just installed Visual Studio 2019 Professional (v 16.7.1) -- work laptop, boss' orders -- and I find that it always crashes when I attempt to dock the Toolbox (for instance) where I want it rather than where "they" want it.
"Working as expected" ?
modified 29-Apr-21 9:39am.
|
|
|
|
|
Easy Peasy. Remove a tool from that toolbox and fix it. The hammer comes to mind. 
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
Software Zen: delete this;
|
|
|
|
|
Not just you. Moving editor tabs around into split windows will hang VS2019 to the point where it may restart itself.
|
|
|
|
|
Same when trying to rearrange window tabs in the editor 
|
|
|
|
|
This ain't Burger King, you can't have it your way!
|
|
|
|
|
what version of VS 2019 are you running?
|
|
|
|
|
Added "Professional (v 16.7.1)" to the post.
|
|
|
|
|
I would update to the latest 16.9.4 I believe. see if that helps you.
|
|
|
|
|
I have no choice over the version, I can't install anything myself.
|
|
|
|
|
Looks like your issue may have been fixed in version 16.8.5. You might want to get on the horn with your IT department and get a new version pushed out. You are working with a VERY old version of VS 2019.
Good luck! 
Visual Studio bug report[^]
|
|
|
|
|
|
Slacker007 wrote: You might want to get on the horn with your IT department and get a new version pushed out
I love absurdist humor. Your sense of the ridiculous is amazing.
Software Zen: delete this;
|
|
|
|
|
that's a legacy feature from VS2015
|
|
|
|
|
This also happens in VS 2017...something as simple as redocking a tab/view causes it to restart. I lost some work earlier this week due to this bug and started using VS 2019 after the 3rd time...apparently it happens there too. 
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
Of the Apollo 11 crew: Astronaut Michael Collins dies at 90[^]
In many ways, he had the hardest job: go there, don't land, and hope they came back to join him ... ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Sad indeed. 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
|
|
DRHuff wrote: will the number hit 0 before it goes up again?
The optimism implied in your question is impressive. Even though the Artemis program[^] claims to plan to put a man back on the moon in 2024, I give it a less than one in ten chance of being completed.
The apathy and moral cowardice of most people regarding a manned space program will cancel all such efforts until it's far, far too late for them to have any impact on humanity's survival.
Software Zen: delete this;
|
|
|
|
|
I've been trying to get the SSD1306 device working with my library, only come to find out that the way the framebuffer keeps its memory is bizarre.
Basically, it's monochrome, so 8 pixels are packed into a byte. But they're packed *vertically*
It appears as though the screen is divided into vertical banks, 1 byte high that hold 8 rows, but those are arranged left to right.
Whoever designed it that way should be punished.
Severely.
Anyway, I figured out a way to change the memory addressing mode, and on top of doing that I flip the whole screen from landscape to portrait and address it that way, and I get some sort of sane horizontal bitmapping, even if my screen is now 64x128 instead of 128x64
However, that mapping mode isn't quite working the way I'd expect.
SSD1306, error - YouTube[^]
I had to post a 3 second video instead of a pic because of the camera->screen refresh interference causing tearing (you'll see what i mean)
I tried to draw a 64x128 hatched rectangle with a solid white border.
That hatched square is supposed to take up the entire screen. It does not, and the border if you look closely, does not appear along the left edge of the screen like it should, and the other side appears but is offset by several pixels as if the screen is wrapping around and offset by like 20 or so.
I can't decipher the datasheet on this addressing mode. It's not clear at all, but it's the closest mode to sanity I've managed to find.
My other option is to do what the other drivers do, and create a special frame buffer in the weird format, then blt everything to that, and force you to call an update() method explicitly to draw it to the screen.
I wanted you to be able to create a bitmap and then use that as your framebuffer, and not have an extra hidden framebuffer stealing RAM.
But in order to do that I need to know how this elephanting memory addressing scheme works, and why it's giving me this output.
I hate datasheets.
Real programmers use butterflies
|
|
|
|
|
I wrote a bitmap font renderer for such a display many years ago, the strange pixel format meant rearranging the font data so it could be rendered quickly at any position with bit shifts and bitwise or's on a seriously underpowered cpu.
That was a fun challenge.
|
|
|
|
|
I didn't design for this. Who makes framebuffers this way? It's just ... meh
Real programmers use butterflies
|
|
|
|
|
It is a well-known "fact" among hardware designers that software is free. The reasoning goes like that: given that software is written only once for any number of devices, its cost is vanishingly small compared to any gate on silicon. So they don't bat an eyelid when they invent stuff like write-only registers (hey, software can keep a copy of the register) or convoluted memory paging schemes (hey, software can change the paging register every 100 instructions or so).
Those of us who have to debug programs with a scope suffer the consequences 
Mircea
|
|
|
|
|
The write only thing over serial i could live with if not for the other thing. But don't mess with me from both directions at once.
These modules these days are almost entirely sold to MCU builders. MCUs don't have spare cycles and RAM for this nonsense. 
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
