You haven't given us all the types and class/structure definitions involved. You are also using a mess of casts and potential aliasing issues. You have to know what you are doing and be very careful to get this kind of stuff right.

anbluemoon wrote:

MD2Mesh::Frame* md2Frame = (MD2Mesh::Frame*)buffer;

Apparently, buffer is a SomeType_T *buffer set to the address of a block of allocated memory. What is SomeType_T? How big a block of memory? What is a MD2Mesh::Frame? How big is a MD2Mesh::Frame? Also if MD2Mesh::Frame is not a pod type, you are dead without properly constructing it via its constructor.

anbluemoon wrote:

uint8* tmp = buffer + 40; MD2Mesh::Vertex* vtx = (MD2Mesh::Vertex*)tmp;

Your magic number could be subject to breakage due to changes. Additionally, it hides your intent. Also don't forget about alignment issues and padding that the compiler can insert in structs. md2Frame now points to the beginning of the buffer. vtx now points inside the buffer.

anbluemoon wrote:

md2Frame->vertices = vtx;

You have now changed part of the contents of the buffer. vtx has not changed at all. It is however a pointer, and what it points to in the buffer has changed because you wrote code to change it. Evidently, MD2Mesh::Frame.vertices is 40 * sizeof(SomeType_T) bytes from the beginning of the structure.

Please do not read this signature.

netJP12L wrote:

First name is John and there is no last name then upon concatanting both names i get null.

netJP12L wrote:

I have set the database "Concatenate Null yeilds Null" to True

It sounds like this is doing exactly what you told it to. You could: 1) follow i.j.russell's suggestion and use COALESCE, [edit - added] 2) try changing the setting, 3) write code that tests for Null and handles the various cases, or 4) don't allow Null values in these fields. Looking through the list, i.j.russell's suggestion sounds very good to me.

Please do not read this signature.

There are both MFC runtime libraries and the C++ runtime library. The linker error messages appear to relate to the runtime library, not MFC. They look to me like the libs referenced expect the runtime library to be dynamically linked. At least some of them appear to be specific to debugging, which would explain why your later post indicates that these errors go away in your release build. Note that there are problems if a DLL and and exe are linked to different versions of the runtime library and one tries to release dynamic memory allocated by the other.

josip cagalj wrote:

I didn't try to install re-distributable file on target machines.

Any dependencies of your program need to be included in your installation. The target machine may or may not have the appropriate versions of the MFC and runtime library dlls installed. This depends on the Windows version. It can also be impacted by service packs and other software installed on that machine.

josip cagalj wrote:

1>With Release version errors are: 1>FileVersion.obj : error LNK2001: unresolved external symbol __pgmptr 1>nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argv 1>nafxcw.lib(appcore.obj) : error LNK2001: unresolved external symbol ___argc

This sounds like an issue with the start-up code. Perhaps some sort of confusion between whether you are producing a console app or a GUI app?

Please do not read this signature.

First, you have bugs in your deleteTree implementation.

Chidori-chan wrote:

free (root->children[i]);
deleteTree (root->children[i]);

This is undefined behavior. Once you have freed the child node, it is no longer yours and you must not access it. Reverse the order of these two lines. There are more problems in your deleteTree implementation as well. I will let you work on finding them. Perhaps I am wrong here, but I would think that deleting a single point actually means deleting the entire subtree starting from that point. Otherwise, what do you do about all those would be orphaned nodes? So I expected to see a call to deleteTree somewhere in deleteP. I didn't find it. Also, I would think that you need to traverse the tree to locate the point to be deleted. I would expect that to be the first thing you would have to deal with, but don't see it in your code.

Please do not read this signature.

Have you considered actually hiding the hidden window: CWnd::ShowWindow( SW_HIDE )? Then it can't have focus and can't be accidentally displayed.

Please do not read this signature.

To add to Mohan Ramachandra's reply, this was a proprietary library for the DOS environment. In other words, this was a graphics library for use in DOS programs only, not Windows or anything else. It was also designed and provided by one company - it is not standard, is not a part of C, and not a part of C++. While you certainly can do graphics for Windows, it is done differently. See here[^] for graphics stuff that is used with windows at the api level, though there is more in knowing when and how to use this stuff. Do note that normally in a windows program, one only draws to a window device context in response to a WM_PAINT message. (If you are using MFC, that would be in OnPaint or OnDraw. ) Graphics and display is different in Windows than it was in DOS. You have a lot of research and reading to do. Good luck.

Please do not read this signature.

After doing a little checking, evidently you can do it with child windows on a 2nd UI thread. You do have to be careful about communications between the threads since there is a possibility of creating a deadlock between the threads. I would still tend to favor using OnIdle() instead of a 2nd thread to try and deal with your performance issue. Apart from some quibbling over precise wording, I don't see the problem with what you are doing. As far as my quibbling goes, in the parent window code you call a setup function passing "this" as a parameter so that the thread class can save its value in a member variable called g_thisParent. g_thisParent is not a pointer to "this", it is a CWnd * to the parent window object. Also, in the second thread, you never, ever use "this" in an attempt to refer to the parent window, you use the variable you have named g_thisParent. Other than that, my only thought would be some sort of synchronization issue - but I don't see what it would be.

Please do not read this signature.

Rozis wrote:

In my apps i use GetAsyncKeyState(vk_shift)!=0 to find out if the shift-key is pressed.

In most cases you want to use GetKeyState() and not GetAsyncKeyState(). If the shift-key was pressed when? Are you processing a particular keystroke? (Such as in an OnKeyDown handler?) GetKeyState() tells you the state at the time of the event that you are processing. GetAsyncKeyState() tells you the state at the instant that you call it. This is not coordinated with where your program is in processing its input stream. For a longer explanation, see here[^].

Please do not read this signature.

Are you using MFC or straight win32 or something else?

Please do not read this signature.

Am I correct that you are: Writing and installing a keyboard hook? Trigger an assertion in your code when you start Internet Explorer? What assertion do you get? What is the code that gives the assertion? Since you are getting an assertion, the place to look is at that assertion. Ask yourself: What is the expected condition that was violated? Can I trace this back from the occurence of the assertion to the origin of the problem?

Please do not read this signature.

I don't think this will work as you are creating them as part of the second (temporary?) thread when you want them to be part of the main GUI thread. Instead, since these dialogs start out hidden, why not defer their creation. Set up a wrapper to create them on first display. This distributes the work so that you don't take the full hit all at once and it should be less noticeable. You could also set up something to create them one at a time in CWinApp::OnIdle(), though you will need to make sure they are not used until created. You could combine this with the create on first demand scheme if you want.

Please do not read this signature.

Hey, this was a great article. It shows you how effective his code is. It even managed to drag the article's entire contents and drop it in the trash.

Please do not read this signature.

Member 590310 wrote:

wat may be the prblm?

The answer:

Member 590310 wrote:

multibyte application ... the resource file is unicode.

Either make the application unicode ( my recommendation), make the resources multibyte, or code the program to transform the unicode resources to multibyte before using them. Also, if you are going to be using multibyte, check that you are using the correct code page for your situation.

Please do not read this signature.

I would imagine that you have enough information to calculate the bounding rectangle.

Please do not read this signature.

A quick answer I just posted got reformatted. Of particular note, all the indentation of the code was removed. I'm guessing that this is the result of an attempted bug fix that didn't quite make it yet. :)

Please do not read this signature.

I won't disagree with you. I like the programming forums. Quick answers isn't yet fitting its use. My other thought was some moderator function for quick questions that didn't fit the mold - perhaps to move it to a forum thread or to change it to a "developer dialog" that would fix the messages in order rather than letting them bounce around by rating. From the link another person provided, it sounds like the design is headed to the format that Stack Overflow uses.

Please do not read this signature.

Have you considered imposing a limit on the number of answers by the same person to the same quick question? Or perhaps a diversion to a page that suggests editing the question / existing answer rather than adding a new answer? Some of these questions develop into dialogs that don't really fit this format. One question I've seen has acquired 60 quick answers, mostly split between 2 people. I have no objections to the dialogs, it just doesn't work with the way Quick answers are set up.

Please do not read this signature.

Eugen Podsypalnikov wrote:

For example: I have implemented the following stage Smile : TOOLDLL <- EDITDLL <- APPEXE -> TOOLDLL

I believe that what Vaclav_Sal was trying was more like:

----------<---------

| |
EDITDLL <- APPEXE -> TOOLDLL
| |
---------->---------

In other words, he wasn't linking one DLL to the other, but was trying to have them use each other by virtue of his knowing that they were both being used by the same exe.

Please do not read this signature.

You're welcome. Thank you for that link in your post to Eugen Podsypalnikov. I didn't know about that possibility.

Vaclav_Sal wrote:

They are both “connected” to the document anyway and need to communicate only with the document.

Sounds good to me. Being somewhat simple minded ;) , I prefer to keep things as simple and straightforward as possible. Keep in mind that you will also have to maintain what you create. I've found that locating a problem when data flow is passing between 8 components, as it does in some software I get to maintain, can sometimes be interesting. Another approach you might consider if you have to notify other windows of some action, but the document's UpdateAllViews() isn't appropriate, is to play "chain of command". Implement a custom message that is sent to the parent window for handling or rebroadcast to siblings of the originator. I've done this with mix-in classes for splitter windows to keep the panes in sync. This has let me reuse views on different tab pages with different - or no - siblings. Oh, I just noticed your reference to VC++ version 6. Are you aware that the dialect of C++ used in 6.0 is non-standard? You might want to consider shifting your development to a later version that is more standard conforming. Good luck.

Please do not read this signature.

Check the icon file that you are using. It does not/should not contain just one image. It should contain multiple versions with different color depths and sizes. (You may have to look around in your icon editor to see how to move between these versions.) You may be missing a needed size/color depth version, so Windows is trying to make due with something else. For some more information see here[^] and here[^].

Please do not read this signature.