|
I still occasionally cycle the country near where I live in southern England. Plenty of hills to challenge me going up, but fun going down. The fastest I have ever been on a bike was 40 MPH (~65 kph) going downhill on a straight clear road in Dorset; but quite a few years ago when I was fit.
|
|
|
|
|
What do you do when it gets cold, snow etc.?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
It doesn't get really cold over here, coldest I've ever cycled in was around -12C, but that's like 20 years ago and it hasn't been that cold since.
But if it gets colder, like < 10C, I put on a cap and gloves and the cycling will get me warm.
I don't even own a (good) winter coat anymore, although I think I'll get one for the times I'm outside while not moving or moving less.
We have little snow, but when we do even lots of cycling lanes are cleared by the local government.
The ones that aren't cleared... Well, let's just say it makes the trip a lot more interesting 
|
|
|
|
|
It helps that there aren't uphill there 
|
|
|
|
|
Thanks for the warning ... I must admit, I am far off-mark for both, but I work hard on it ...
|
|
|
|
|
It's just past noon and I'm sitting here drinking a cup of coffee; result!
|
|
|
|
|
Nice, my addiction finally payed off! 
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Immortality, here I come!
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I find this set of Microsoft Visual C++ 6.0 MFC reference library on ebay. its tag price is $90.
I am only interested in the MFC library reference Volume 1&2, so I am not willing to pay the tag price. not ready to give up, then I searched and find this set in thrift book with only $8.00. I order this set yesterday night.
Recently I am interested to know the origin of MFC library and try to pick something legacy. I am amazed to see MFC library still works well and evolves nowadays.
diligent hands rule....
|
|
|
|
|
|
thanks for this thread, I almost forgot this.
I got my answer from a legacy book on MFC already with the confirmations from this community.
diligent hands rule....
|
|
|
|
|
I had VC++ 6 and the reference disks but not sure if I still do
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
the chapter on resource file is really enlightening to me: I did not find it in other books.
maybe it is too simple topic...
diligent hands rule....
|
|
|
|
|
I had it all on a XP VM but when I upgraded to Win10 I lost it. Don't know if I still have disks or not, they're buried deep somewhere in an old drawer if I do still have them.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
There were a lot of tricks when the entire windows system ran in 512K of memory. Resources were designed to quickly load, do something with them for the GUI and allow for a quick memory reclamation. E.g. the resources for a popup menu might only be retained in memory until the user selected an item or cancelled the menu.
Throw the resources into a DLL separate from the UI exe and that is the only thing that needs to be translated.
Exe loads the right DLL based on locales.
rc- resource compiler was always a separate make.exe step before linkage.
The slowest part of any GUI is usually the user.
MFC is just a convience layer on top of the C based OS layers.
I am agreement with another poster (maybe you?) that the backwards compatibility for Windows has been incredible. I still use a utility on Win10 that predates the scroll wheels on mice! It barfs on double byte encoding, but use UTF-8 for most items so it is fine.
|
|
|
|
|
good to know these history of resource files
diligent hands rule....
|
|
|
|
|
Why buy the books? I remember VC6 came with the MSDN documentation that can be installed on the computer from the DVDs. As for your "MFC evolves nowadays" comment, MFC evolves with newer Visual Studio with bug-fix and new features. Why bother with such an old product?
|
|
|
|
|
somehow I like the paper touch instead of staring at screen
diligent hands rule....
|
|
|
|
|
|
thanks for this great link!![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif) it is worthy for me to post this message:
diligent hands rule....
|
|
|
|
|
I am not sure what you mean by "evolves" because it has been in maintenance mode for quite some time.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I see some extension methods from legacy MFC methods...
diligent hands rule....
|
|
|
|
|
I thought this might stir up a few of the 'traditionalists' on here!  Rather than answer the many comments individually, I'll try to respond with this single post.
I had spent nearly 5 years developing COBOL applications before our boss told us about the Pick database that we were going to be moving to. To be honest, I couldn't see how it could possibly work and raised the same concerns that have been posted here today. There are a couple of common observations:
Including 'DB rules' in the code/UI. First of all, we already do this. I'm pretty sure most developers would define the MaxLength for a TextBox and use a Calendar Widget for date input. Secondly, validation logic should be developed as reusable code - which minimises the need for future developers to learn and re-code that logic.
Performance. You are going to have to take my word for it, but I am 100% sure that with less disk, less CPU and less memory, I can deliver better performance than could be achieved using a traditional RDBMS. Also, indexing data does not have a performance hit. And the greater the volume of data, the more confident I would be that performance would be better.
|
|
|
|
|
Your mileage will vary. Particularly regarding indexing. Needless/useless indices definitely waste resources. The application you are working on may be very different from mine. Don't generalize based on one particular type of application.
I'm not real sure what you are on about though.
|
|
|
|
|
Hmmmm,
Many years ago I was tasked with writing a VDR[^] for the IMO[^] and the Det Norske Veritas[^] and most of the signals were coming in at around 10Hz and I was required to log them in 'real time'. Back then the IEEE defined 'real time' as 1.5 times the signal rate.
For performance reasons I chose SQLlite[^] and a single BLOB[^] in the voyage data recorder.
Worked great for a few years. Then we had two incidents, "incidents" in the maritime industry usually means millions of dollars of damage or greater. No problem I thought, let's pull the black box and see what happened!
The BLOB fields did not match the C++ structs we were using for logging the signals, something was off. After a lengthy forensics analysis we realized that the office in Norway was using a different build and the Norwegian C++ structs did not match with the U.S. code. They were somehow compiling the vessel navigation software with different signal headers.
The 'BLOB' field did not give us any evidence of what was different and we wasted an enormous amount of time investigating this. Also... these millions of dollars of damage were disputed between multiple nation states. In the maritime industry these judgements are decided by arbitrators rather than an actual legal system.
[cheers]
modified 28-Aug-21 5:48am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
