The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
1. The lounge is for the CodeProject community to discuss things of interest to the community, and as a place for the whole community to participate. It is, first and foremost, a respectful meeting and discussion area for those wishing to discuss the life of a Software developer.
The #1 rule is: Be respectful of others, of the site, and of the community as a whole.
2. Technical discussions are welcome, but if you need specific programming question answered please use Quick Answers[^], or to discussion your programming problem in depth use the programming forums[^]. We encourage technical discussion, but this is a general discussion forum, not a programming Q&A forum. Posts will be moved or deleted if they fit better elsewhere.
4. No politics (including enviro-politics[^]), no sex, no religion. This is a community for software development. There are plenty of other sites that are far more appropriate for these discussions.
5. Nothing Not Safe For Work, nothing you would not want your wife/husband, your girlfriend/boyfriend, your mother or your kid sister seeing on your screen.
6. Any personal attacks, any spam, any advertising, any trolling, or any abuse of the rules will result in your account being removed.
7. Not everyone's first language is English. Be understanding.
Please respect the community and respect each other. We are of many cultures so remember that. Don't assume others understand you are joking, don't belittle anyone for taking offense or being thin skinned.
We are a community for software developers. Leave the egos at the door.
Brexit has been an absolute boon for Northern Ireland, We Really have best of both worlds here now. The unionists here are too stupid to understand that, but, I'M not surprised. That crowd wants to return to 1950. Above that, A United Ireland is now in sight. Island wide discussion are taking place about reunification! Good all around! The EU Protocol works very well INDEED! It gives the reactionary Unionists here a well deserved Toe up their arse! They wanted the harshest Brexit ever to get an Irish Border on the island That backfired, the border is now in the sea.
I've been spinning my wheels on a simple design issue I can't decide on for the life of me.
I've spent a quarter of the time on this actually writing code - which works, and does everything it needs to - and the rest of that time I've spent on basically one method, and what to return from it.
All to switch screen modes, and all because different screen modes *must be* different actual types.
So you have to return something from a screen mode change operation that you can draw to.
What do I with the old draw target from the previous mode???? This isn't even something I can really ask someone about.
I hate problems like this. They leave me feeling paralyzed and frustrated because I can't just code my way out of it. I can't put myself in the shoes of a person using my code in this instance to a degree that satisfies me. So I can't answer the question.
I've got $150 worth of hardware that was donated to me on the premise that I would write driver code for it, and I'm stuck on this one stupid issue and at this point it is ruining my day.
Yes, I've already taken a break from it. That's why it is taking so long. The question isn't difficult. It's just difficult to decide.
Anyway, I'm just venting, and also typing this in hopes that putting it out there might lead to me making some headway, as happens occasionally.
That is one of the options - to fail on subsequent drawing operations.
The other - trickier but doable option is to allow both to continue working, but at the expense of more memory usage (since its holding both frame buffers), and the fact that your whole screen will change when you start to draw to the original target again.
I don't want this to be too difficult for people. That's one of the reason I kind of don't like the failing options. The problem with failing is that in this environment I cannot use exceptions. If people don't check return values, the fails are all silent.
But maybe in this case that's for the best. After writing this out to you I'm leaning toward that.
Ask me about the application I began in 2009 and still haven't committed to a decision about a design choice I thought I had made.
Back in the 80s (? I think it was in Turbo Pascal at that time) I had also stalled for a year while working on a game -- I needed to decide how to score a roll of dice. But I eventually finished that one and later updated it to C# and WinForms.
Something you mentioned earlier comes back to mind. Maybe changing your point of view is what's needed.
Switch over to writing a use-case for this API. What's the most useful behavior for what's being returned? If only one 'thing' can be active, and the returned item is no longer the active 'thing', then what about making the returned object read-only? You can return information from it that either doesn't require the active state, or is a copy of the last value held while the 'thing' was in the active state.
Whenever I've been in this state, pounding my head on the desk trying to decide something, it's always been the case I was looking at the problem incorrectly.
I'll admit I've used a brute-force solution fairly often of making the simplest decision and implementing it, knowing that it wasn't adequate and would fail. Iterating through this again and again, while looking wasteful, was a way of eroding the mental block. The act of implementing an idea, making it concrete, puts the brakes on the fruitless "nope, nope, nope, nope" cycles. Getting down to the details of each inadequate solution helped me learn about the actual shape and edges of the problem.
This also lets you throw something at the problem other than your peace (piece?) of mind, which is useful in my environment. Good luck.
Absolutely. I've been telling myself, just code it, and then deal with it, knowing that if I choose poorly, I'll have to rewrite 90% of the driver code because of how it operates. The design decision has ramifications that impact the entire driver's codebase.
It's just tough to get that motivation to continue going feeling like I'll probably have to do it over again. Or at least I think that's part of it.
I'll work through it eventually. I feel a little obligated to make it a priority based on me accepting goods in exchange for my coding, even if it was informal. Just a little pressure though, not a lot.
I can't put myself in the shoes of a person using my code
As far a I'm concerned, you're already ahead of the game by just considering another person using your code. I see far too many implementations where "oh, someone else might use this code besides me" clearly was never considered. Particularly the way API endpoints are coded. Definitely a WTF, as I see endpoints that are unusable except for the very narrow use case of a specific front-end implementation.
Without code to go on, this is very speculative. Even code might not help, because of the time that would be needed to study it, trying to infer the design rationale before providing what might have a shot at being useful unsolicited advice.
But why should any of that be a barrier?
1. How about returning void? The user must know they're switching modes, so they should adjust accordingly.
2. If switching modes can fail, even because of bad arguments, then a bool would be better.
3. If the previous mode can no longer be used, how about returning the new one? Can't it actually be returned?
4. There's also a "draw target". How about returning that?
5. I assume there's a "handle" to which clients write, and that it's polymorphic. So can the new one be returned?
Here, my_draw_target is what gets drawn to. above draws a point at (10,16), color of red
my_draw_target in this case, is say, screen mode 0
but I now want to switch screen modes
// switch the driver to a new screen mode:
auto my_draw_target2 = driver.mode<1>();
// now draw to the new screen
In the above case, once you have my_draw_target2, my_draw_target becomes persona non grata. How that is handled is the question, meaning what happens if i then try to draw again to my_draw_target?
PS: It may appear that my_draw_target and my_draw_target2 are polymorphic but they are not. They do sort of have a shared interface, but they don't. It's complicated. I bind using templates, not virtual base classes
I suspect he was just trying to uninstall himself ...
"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!