This part of the site is dedicated to explore
knowledge I obtained myself and to a lesser or greater extent been used by myself. In IT, computer
programming field.
Projects:
→Tic-Tac-Toe
→FTP server
→Semern: Word Statistics
→Artem: Web Album Generator
→Interferometer: Stripe pattern autotracing
→BMP viewer
→Video Player based on Video-For-Windows technology
→Camera Switch
→RSS Reader
→TV Telephone Vote System
→Wave Parser
→Video/audio mixer on PCI card
→Slideshow
→DVB multiplexor
New programming jargon→
Good app is for dumbs to use, with unlimited power to offer.
There should always be a single place which would provide a similar kinda service for many recipients. Even if they ask for a slightly different outcome, but most of the code is pretty much the same, then it nevertheless should be implemented in single place with input parameter list.
Otherwise what happens is you realize you need to fix something (which happens all the time) – now you have to fix it in N places where you've replicated that code. Right? Is that what you want? Of course not.
So, implement code only once at then *subscribe* all the clients to that server.
I always wondered why old-school programmers don't use new fancy
bool
type instead of BOOL
? Well, it's because all the Windows API
is written in old C and there can't be direct assignment from one to another without cast
or warning message. So, old school programmers just use the old approved variant.
There is completely simple idea about maintaining a GUI-based application, when a new feature is required: (1) build and make sure it's working; (2) put it upon the GUI.
There are different ways to debug a new feature without putting controls on the GUI or changing it in any way. We always may read feature-related data from standalone file, registry and so on. No need to change the GUI.
So, debug the engine first, then change GUI.
It is extremely important to call AfxOleInit() instead of CoInitializeEx(NULL, COINIT_MULTITHREADED) when your application is multithreaded. And it's not about magic.
Let's consider a case when a second thread in your application can be released asynchronously so as it quits after the application does. And also your separate-threaded-class has some COM-pointers which are to be released in its destructor. So the application quits accidentally (an user clicks X-button) and it uninitializes the whole COM-machine. Further behaviour is unpredictable but in most cases application (I mean that separate-threaded-class) becomes unable to release it's COM variables and there happens a memory leak.
In short: use AfxOleInit() instead of CoInitialize().
A basic idea about MFC device context (DC).
Many times I wanted to fix this question. And now here I go: CString & multithreaded applications.
As we read from the MSDN CString is an object that shares one big buffer between several instances. It uses copy on write mechanism. This is why every one is to be better aware of it when he or she writes a multithreaded application.
Let's consider two threads A and B and two instances SA and SB of a class containing CString member. Now imagine a situation when SB is being assigned to SA WITHOUT having a copy constructor reloaded (in order to make SA.str another separate instance of CString equal to SB.str): it just becomes using the same memory in two distinct threads. I'm pretty sure (many times got it :) this application gets an access violation very soon after a start.
Solution is rather simple: rewrite the default copy constructor so as it allocates another memory for the copy of CString being copied.
There is a phone vote application I'm working on and I need to add a possibility to get the statistics from internet (not using a special phone adapter receiving calls and communicating with a PC via USB-port). And hence there are couple questions to discuss:
Many people blame XML for it's redundancy (as my teacher likes to say: «we send our e-mail as an xml file with 30 bytes of information and 300 bytes of meta-information so as the CPU has to do something»). However there are plenty pluses of XML. And the major one is that it is easy to figure out what's wrong using a naked eye.
I need to distinguish responce variants from lines that support those variants.
See, there are several (from zero to many many) lines supporting each variant. And I have to gather calls from lines, not variants, cause each line has it's own factor, so that the final variant calls amount is a summ of dot products of line calls and line factors (in fact it's a little more complex since there can be manual entered calls).
Finally, the XML structure is gonna be like this:
<statistics> <line number="1" calls="16"> <line number="2" calls="42"> <line number="3" calls="30"> <line number="4" calls="70"> <line number="5" calls="40"> <line number="6" calls="87"> <line number="7" calls="12"> <line number="8" calls="43"> </statistics>
There is a tricky issue about downloading a file from internet (being precise I mean Hyper Text Transfer Protocol — HTTP). And that is when I try to retrieve a file from a server that does response to a ping but doesn't actually give the file, the process hangs up. Now, I really want to hammer this point: it's not the file doesn't exist at the specified URL — no, it does exist — server just doesn't send it for some reason.
In this case it's obvious that I can not make a synchronous request. Cause the whole program will wait upon the http-request completion which is not going to end in a second, minute or even an hour (it was a case when I didn't get that request the whole day! Well, of course I didn't wait for it, I was developing another application). So, I need to request data asynchronously and make the receiver able to send to main window a message that data is received and ready to use.
GDI, WinAPI → MFC → Windows Forms → WPF. Designers (applications that generate XAML
-code which marks up the GUI: Orcas, Expression Interactive Designer.
Our human eyes are differently sensitive to different colors. That is why after people invented color TV (with Red Green and Blue separate independent colors), in order to save many perfectly functioning black-and-white TVs, they began to distribute a television signal within the same single wire giving those three colors the following factors:
R → 0.299 G → 0.587 B → 0.114
so the black-and-white signal Y became exactly this:
Y == 0.299·R + 0.587·G + 0.114·B.
Simultaneously, color TV sets used three wires:
which are to be transformed into RGB signal in a very simple scheme:
R → U + Y G → Y - 0.509·U - 0.194·V == Y·(1-CR-CB)/CG + U·(-CR/CG) + V·(-CB/CG) B → V + Y
This signal is called COMPOSITE video signal and used in many technologies (for instance, VHS which is Video Home System).
Ivan Yurlagin,