C / C++ / MFC

Indeed. I had to install the 64-bit Oracle client. Now I'm trying to config the application to use 64-bit or 32-bit Oracle client according to the processor type using the configuration in the app.config: Thanks for your help Dave.

jpg2tga.cpp is not actually part of the library. It is an example program. However, if you really need such a functionality you could try to modify the code (if possible) to fit your needs. Another option could be using an external (serial) RAM. THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?! -- C++ FQA Lite

Accident.

You need to look up the inheritance chain to see what features are made available through its parent classes. The ClistCtrl[^] class provides what you are looking for.

It turned out that I was looking in the wrong file. The problem as the App definition file not the dialog defionition file.

So the icons don't match. All that tells you is that the icon for the message window is not the one you were hoping for. The chances of you being able to use this code in a production environment are not very high, since very few applications will be doing things the way you expect or want.

Please read HOW TO ASK A QUESTION[^]. This site does not provide code to order.

http://automatemytasks.weebly.com[^]

Sorry, I don't know the answer. I can only suggest you try some further searching, or maybe one of the Microsoft forums.

So? THESE PEOPLE REALLY BOTHER ME!! How can they know what you should do without knowing what you want done?!?! -- C++ FQA Lite

Have you looked at the GetMenuBarInfo function? You can get the RECT of the menu-bar with this function. I.e MENUBARINFO mbi; mbi.cbSize = sizeof(mbi); GetMenuBarInfo(hwnd, OBJID_MENU, 0, &mbi); printf("menuBar rect (screen) = %d,%d,%d,%d\n", mbi.rcBar.left, mbi.rcBar.top, mbi.rcBar.right, mbi.rcBar.bottom); MapWindowPoints(HWND_DESKTOP, hwnd, (LPPOINT)&mbi.rcBar, 2); printf("menuBar rect (client) = %d,%d,%d,%d\n", mbi.rcBar.left, mbi.rcBar.top, mbi.rcBar.right, mbi.rcBar.bottom); Notes: 1. All of the members are 0 during the WM_CREATE message handler 2. The dimensions returned are in screen-coords. Example output: menuBar rect (screen) = 108,130,636,149 menuBar rect (client) = 0,-20,528,-1 When I tried to change the DPI setting with the program running, I was told I'd have to logoff and then login again. Am I correct in assuming that you change the DPI and _then_ open the program? Also, is this a standard menubar, or is it an instance of a toolbar that's been added to a rebar control? The difference being that a standard one should be a part of the non-client area, and therefore the toolbar you have should be automatically moved down to accomodate the menubar having larger text. If however, you have a toolbar inside a rebar control as your menu, the rebar container is a part of your client area, and you need to manually position the toolbar below it. Different DPI settings will change the required height that you need to offset the toolbar by. Can you upload a screen shot somewhere and post a link to it?

It's just bytes... use one of the many IPC types[^]. Sockets are likely your most commonly used IPC nowadays for a number of reasons, but there's always other options that have different benefits (and drawbacks of course). For example, simply having a shared file would be very simple since you just have to write the file to a shared location and then have a way of notifying the other application of the new file to process (notice can be done via Windows message or other such messaging mechanism, or simply have one application launch the other and load the proper file via command line arguments). You have a lot of options, you have to decide what's important then implement accordingly. Happy coding! :)

Do you understand what MTU size is? If not look it up ([^]) The basics are: UDP over IP uses an 8-byte header added by the UDP protocol and a 20-byte header added by the IP protocol. So +28 bytes of data in the header. TCP over IP uses a 20-byte header for the TCP, and again a 20-byte header added by the IP protocol. So +40 bytes in the header. So those are the headers and then will follow your data which will be in sizes making MTU block sizes. The data in the headers is referenced here UDP header http://en.wikipedia.org/wiki/User_Datagram_Protocol[^] TCP header http://en.wikipedia.org/wiki/Transmission_Control_Protocol[^] The IPv4 header http://en.wikipedia.org/wiki/IPv4_packet#Packet_structure[^] In vino veritas

Do the obvious thing start by looking at something like NotePad++ which the source code is open. http://notepad-plus-plus.org/[^] In vino veritas

for every pixel, calculate: Gx = -1 * p(x-1,y-1) + 1 * p(x+1,y-1) + -2 * p(x-1,y) + 2 * p(x+1,y) + -1 * p(x-1,y+1) + 1 * p(x+1,y+1) Gy = p(x-1,y-1) + 2 * p(x,y-1) + p(x+1,y-1) - p(x-1,y+1) - 2 * p(x,y+1) - p(x+1,y+1) + pOut(x,y) = sqrt(Gx * Gx + Gy * Gy) (this is from Wiki) image processing toolkits | batch image processing

One way to do it is by adding (pure) virtual accessors that read the elements that you need for the addition, and (pure) virtual factory methods that you can use to create an object of the correct type. The following might work: class vecbase { public: virtual int size() const = 0; virtual int& operator[](int i) = 0; virtual int operator[](int i) const = 0; virtual vecbase create(int sz, int* values) = 0; friend vecbase operator+(const vecbase& a, const vecbase& b) { assert(a.size() == b.size()); int* values = new int[a.size()]; for (int i = 0; i < a.size(); ++i) { values[i] = a[i] + b[i]; } result = create(a.size(), values); } }; Note that I declared the operator as a friend function, rather than a member function. I prefer that approach for binary operators in case I need operators for mixed argument types. The functions in the derived classes should then change the result types of the overriden functions to the appropriate type: class vec2 : public vecbase { private: int val[2] public: vec2(int* values) { assert(values != nullptr); val[0] = values[0]; val[1] = values[1]; } int size() const { return 2; } int& operator[](int i) { return val[i]; } int operator[](int i) const { return val[i]; } // change return type on this override - it is tstill considered an override! vec2 create(int sz, int* values) { assert(sz==2); return vec2(values); } }; I haven't tested this or even compiled, but this should be good enough to get the idea. P.S.: just realized that I forgot to release the values array - that one will be a bit tricky, maybe you need additional pure virtual helpers to create and release a sufficiently large initialization array... P.P.S.: I just realized this could be done much easier - all you need is a pure virtual function that performs the addition, and creates the resulting object as well: class vecbase { ... virtual vecbase add(const vecbase&, const vecbase&) = 0; friend vecbase operator+(const vecbase& a, const vecbase& b) { return add(a, b); } }; class vec2 : public vecbase { ... public: vec2 add(const vecbase&, const vecbase&) { ... } }; Of course, that defeats the purpose of implementing the operator in the base class - but then you can't really do that without virtual helper functions anyway. GOTOs are a bit like wire