Comments by michaelmel (Top 53 by date)

It was actually me - I gave you one because I thought it was a bad answer. Doesn't necessarily make me a moron and doesn't necessarily make my views any less accurate than yours. Imagine all you like.

There are generally 2 serial numbers related to the disk:
1) The volume serial number that you can get through GetVolumeInformation function. Basing any copy protection on this number will not be secure because it can be changed.

To view the volume serial number, go to DOS shell and do dir /p

Here is an article that describes how to change it:

Changing volume's serial number[^]


2) The manufacturer-specific serial number (I don't know how to get it and suspect it will be difficult as you have to take care of different OS-es and disk systems e.g. FAT NTFS etc)

Hope this helps.

It is the same on all PCs if they have a serial port (eg RS232)- for some reason, it is always the same address. At least on Windows XP.

Not sure if the same happens when there is a USB to RS232 converter used.

I think we both are showing our age here :)

Looks like plain old ANSI C to me, NOT C++.

Given that your particular PIC is a very low end micro, with something like 14K of program memory, I would say one would fail spectacularly trying to use C++ to write programs for it (even if you find a C++ cross compiler for it which I doubt).

Correct - there is no other way other than overriding OnPaint, Marius is right.

1) The link was intended as a general reference to some of the issues involved. Sorry if you think it is irrelevant to your immediate issue - you are probably right. I think it is a well written article though;
2) The term "double buffering" is actually ambiguous. What most people understand by it these days is preparing the complete image outside the actual screen memory (e.g. memDC in your case) before very efficiently copying it to the actual screen DC. Hence two buffers. But even with this, flicker is possible as physical display memory is modified whilst the display hardware controller is simultaneously using the same memory to blast pixels to the screen.

True double-buffering is done using 2 or more screen buffers and switching them on hardware driver level. In particular this was relevant for CRT monitors where buffer swap had to occur during retrace (e.g. whilst display is not being updated).

The bottom line is, with your BitBlt you have no control over flicker. You will have greatly reduced flicker and appearance of smooth rendering if you fully prepare the image "offline" and then quickly copy it to physical DC, but you cannot guarantee it will be completely flicker free on all monitors and refresh rates.

Sorry for long-winded response and if is irrelevant to what you were actually asking- my bad.

Do you get any data?

This is partially incorrect. Explanation in my solution.

If you opened socket with a keep-alive option, TCP will automatically send a heartbeat message to monitor the connection and close it if it is not alive. From memory, keep-alive is default option with Winsock and most UNIX/Linux implementations.

The other option which I use a fair bit is to send my own hearbeat packet into connection (both ways). This also has the advantage that intermediate devices such as routers don't try to be too smart and drop the connection as inactive - as it always has some (small) traffic.

Generally, in your 4th step, if the connection is not alive, your send() will return an error. Generally, your connection can remain active indefinitely, even if idle.

Sorry systemerror. We should have not used your question as a place for an irrelevant discussion.

I don't know the exact answer to your question I don't use CLI. Sounds like Wes Aday knows what he is talking about have you tried his suggestion?

Your answer is irrelevant to the question asked. Therefore, it is useless. May be he had the code working at 10 a.m., made a change that broke it at 2 pm and his company policy is to do check-in at the end of the day. How would revision control help then? In my opinion, if you have nothing to add regarding the direct question, there is no point in doing a lecture on a different topic alltogether (like revision control).

With all respect, hardly a relevant lecture on the importance of revision control. It is one sweeping statement to say that unless something is placed under revision control it has no value.

I had to write exactly what you are after (extended version where multiple clients can be connected and one client's data can be sent to 1 or more other clients). Unfortunately it is embedded in a proprietary application and I do not own the source code so cannot post it. I am pretty sure you will not find anything off-the-shelf to do this. If you end up writing it yourself, let me know I can give you some tips on design. Pure 1:1 data relay is actually very simple.

OnButtonClickXXX are just regular functions called through event handling mechanism. What you see in the function body is what you get. There is absolutely nothing wrong or weird with calling OnButtonClickXXX from another function, including a timer handler e.g. OnTimer. Full marks to Argonia from me

I am confident that unless we are stretching semantics to absurd levels, a linked list is NOT a database. The same applies to other types of collection classes and data stores.

Whilst in most general sense "database" is simply a collection of data, in real life the term is narrower and implies something a bit more permanent than transient data (such as linked list or array in RAM).

There is a massive flaw in logic - what does it have to do with CAPITAL letters? And, in fact, with letters in general - it should work on any characters. Using embedded constants -why 26? - at least #define it somewhere. Not parenthesizing e.g.: return to_test <= 'Z' && to_test >= 'A' - whilst precedence is correct coding style is bad in my opinion. There is nothing wrong with functions with more than one loop even if they make you dizzy. And finally, your solution is overcomplicated and bulky, especially in the context of the question.

1) Droplets of C++ won't hurt. Makes it more compact. The only non ANSI-C thing in the code is BOOL type and initialization for i, j, k variables. Something for the poster to ponder on (after all, we are doing his homework, aren't we?)
2) It is written intentionally in a way that a student can understand hence "found" variable. It is HOMEWORK, remember? Besides, I cannot see how it can be eliminated without changing the solution substantially.
3)
It is not a "variable number of arguments function" - where did you get that idea?

Ernst, just a few points there:

1) There should be something like GetListCtrl method in List View class (I know I keep thinking about MFC but relationship between views and underlying controls is implemented similarly on all SDKs) which should return a handle to the list box object which is what you want I think.

2) Re compiler errors - C/C++ compilers will only complain about unknown object without even checking what is being dereferenced on that object. E.g. if ListBox1 is unknown, they will tell you about it (e.g. undeclared identifier error) and stop analyzing the rest of that statement. What I am saying is there is a flaw in the logic of assuming that "term GridLinesHorizontal itself is known to the compiler". Only if the object is known you will get messages such as "GridLinesHorizontal is not a member of ListBox1".

Sorry if I misunderstood the question and made some wild assumptions as to what you wanted.

Have you even read the question and my answer?

I am saying it is NOT important UNLESS it is a R/T application.

From the question it doesn't sound at all as a R/T app.

Yes it probably was the right code - router without port forwarding would refuse connection on a requested port - error code sounds about right.

A logical thing to do would be to get it to work first on 2 computers (clien and server) that are on the same subnet. I get an impression that the only time this software works is when you use a loopback address e.g. both client and server run on the same PC (or may be I misunderstood).

When this part is working, you can try setting port forwarding on the router -e.g. open one port number and map it to your server's private IP address. If set correctly, remote clients will be able to connect to your server running on your private subnet. Well, at least until your ISP decides to change your IP address :)

Have you even tried to ping your "external" IP address? But then again, ICMPs are often blocked these days.Sounds like a firewall problem to me as well.

As Code-o-mat alluded to, if your client is attempting to connect to a server that has a private IP address and sits behind a router you generally cannot do it without tricks.

For example, if I have a subnet 192.168.x.x at home and if I want to run a server, the external client needs to attempt a connection to an IP address of my router (which is a routable public address that your ISP provides), not the server PC directly. Inside the router you can set up "port forwarding" which means all traffic sent to a particular port will be redirected to an internal IP address (e.g. your server with 192.168.x.x something address). Hope this is relevant.

No problem, cheers.

I doubt anyone will be prepared to actually write it for you as it would defeat the purpose of the assignment. I think I have pointed you in the right direction.

After you "kicked" the console application in the UI, you could just wait for file tmp.txt to be created by the console. When UI finished reading from file, delete tmp.txt. Then the whole thing repeats. This will work unless console continuously produces output in an asynchronous manner. If this is the case, you can still read the file, just need to use an appropriate type of file access. I think overlapped I/O should do it.

Don't think it is a tricky question, probably a typo. I suspect in question #5 the esteemed professor meant to have the following ERRONEOUS code in line 2:
delete abc_ptr;
This would match the heading of the question #5.
The way it is written, e.g. delete [] abc_ptr; is correct.

Richard, you would have noticed I deleted my comment (for the very reason that, as you have said, I cannot possibly know how much you know on the topic and hence my comment was unfair in that respect). But since you have decided to re-post it, here are some more prejudiced opinions.

If you perhaps try to understand a bit more what is the level of the person who is asking the question, you will realize that in this case, there was only a miniscule probability (simply based on the fact that it is a relatively tricky question) that the person who has asked the question hasn't first tried to find an answer in the MSDN documentation. Therefore, in my opinion, it is not really helpful, and is patronizing just to tell the person to head off and check documentation when you cannot clarify what it is exactly that you mean. I understand that you perhaps don't have the time to get into all the details of every post you are trying to answer, but it is hardly helpful to point out to MFC programmers that MSDN online documentation is in existence.

You could do exactly the same in WM_LBUTTONDOWN handler. Put the same code in OnLButtonDown as what is in OnSelchanged. E.g. get the selected item and then retrieve its text, whatever else is required.

If your design is such that both sides should be able to act as a server (which sounds like a type of peer to peer protocol), then yes, both will need a global IP. However, chatroom is a bad example - you could host it on a server with a global IP, and let your clients (people who want to chat) connect to it. Clients do not need a global IP address themselves, but they will need to know the server (best done through DNS). So, the clients talk through the server. This is how (almost) every chat/messaging application works on the net.

As posted, the solution would allow only one item to be selected at a time. However, this is not directly related to how you do selected and unselected images. I never needed to have more than one item selected in a tree control as it is rather rare user interface style. But sounds you already worked it out, well done.

Hard to say why it locks up. I have never used the wrapper you are using. I feel it is an overkill personally to pass data through windows messaging if you can have a simple shared data buffer accessible by 2 threads. The arrangement with 3 threads and Rx and Tx data buffers works for me in quite a few apps. Sorry this may be a bit vague.

The comment was effectively an addendum to your answer. Are you asking me not to comment on answers in general? Or just your answers?

Also, I do not see the need to wait for events on serial ports. ReadFile will nicely suspend the receive thread until the desired data arrives, or until a timeout occurs. May be you don't need the wrapper if it cannot set receive timeouts. This would be even a simpler design.

That is correct. For serial comms I always use 3 threads: 1 receive, 1 transmit, 1 for user interface. I do not use windows messaging for exchange of data between comms threads and the user interface thread, instead I use 2 simple, thread-safe data buffers, one for transmit data, one for receive data. Works perfectly well for me. My hunch is bypass Windows messaging and try just a shared data buffer (protected by Critical section or something) and see if the same problem occurs.

Tush

1. Get Microsoft Visual Studio
2. Create a new dialog-based project
3. Add code that I posted to your project. Normally you would put the code in 2 files (one *.cpp and one *.h)
4. Add 2 buttons to the dialog template, one called Set, one Clear
5. Add BN_CLICKED event handler for handling single mouse click for each of 2 buttons
6. Add an instance of CComPortDriver to your project. You can make it a member of Application-derived, Dialog-derived class or even leave it global. You need to know a bit of MFC to know what I am saying, sorry.
7. In the function OnInitDialog, open port (call "Open")
8. In the event handler for "Set" button, call SetDtr()
9. In event handler for "Clear" button, call ClrDtr
10. Compile and run your project
11. Observe DTR pin change state every time you click Set or Clear
Port will be closed automatically when application exits.

This is as simple as I can explain it.
Sorry I cannot give you a tutorial nor CodeProject Q&A is this a forum for it. I am not able to spend a lot of time on this at the moment.
You probably have to learn some C/C++ and Visual Studio before you can understand the code and what I am saying.

Best regards & goold luck

This code is written in C++. You will not be able to compile it using a plain C compiler.
This code will happily compile using Microsoft Visual Studio C++ at least from version 5 upwards.
To use the code to do something real (like toggle a pin), include an instance of CComPortDriver in your CWinApp-derived class, and then call corresponding methods (e.g. Open, SetDtr, etc). I am sorry I cannot teach you a lot of C or C++ on this thread.

Here it is - see solution #9. Sorry about delay, time zone difference.

I cannot see how is the code in the link has anything to do with the question asked.

Thanks Peter, you pointed me in the right direction. I will probably do a Monte Carlo type experiment on how good it is by generating sets of random strings and measuring the average number that it takes to reach the collision.

Obviously I expect a much higher than 0.5 probability of collision for 77000 strings given that the formula is, as you point out, for an ideal hash function which djb2 is not.

My app checks for hash uniqueness anyway and if there is a collision, it switches to slower searches by string. This is why I need two strings which produce identical hash so I can check this switchoever mechanism.

Cheers,

Michael

Well, I do work in life safety related industry :)

Of course you can disable that (unwanted) feature/style be calling SetListStyle without LVS_EX_TRACKSELECT bit set - best place is to do this is in the OnInitialUpdate method.

No worries.