|
|
Actually thats where I started. I have a callback and StreamIn function but theres never any output in the RTBox. I have some sample code that I can post if you would be interested in looking at it.
Thanks,
ns
|
|
|
|
|
Hey all,
This is probably the wrong place to ask, but...
Anyone know of a (really simple) application/library that can take a series of 3D coordinates (1 set of coords for each second, for example) and render it as an animated point in 3D space?
I need this to test the output of my app, which uses fancy photogrammetry to derive an object's 3D position based on it's position in 2+ camera's image-plane.
I need something that is as simple/quick to set up as possible, cos I can't really afford to spend loads of time learning OpenGL/Direct3D, etc.
Any pointers?
TIA,
Pete
|
|
|
|
|
|
You could write out a VRML file and use a free VRML viewer.
Todd Smith
|
|
|
|
|
There is one called Scenelib that is pretty easy to use and is based on OpenGL. I can't remember where it is right now but it should be easy to find with your search engine of choice.
The Ten Commandments For C Programmers
|
|
|
|
|
I'm cofused,and need help.I'm programming in MFC.What I want to know is how to use 'm_pSet->Insert()' to add a new row.I just had a try.But it doesn't work.Nothing is added but a row has been modified.Would you like help me with problem?Thank you.
|
|
|
|
|
Hi all !!
I am developing an instant messaging server which will also connect to databases. I am a newbie as far a data access in VC++ is concerned.
Now i want to connect it to database server (client/server model). Please suggest me the best data access technique considering the requirement of my application as follows:
My application is DOS based, 90% complete and written without the usage of MFC.
I want to access data from sql-server based machine running on my network. My target is to access data quickly and efficiently though accuracy can be compromised.
Programming ease is also a requirement.
|
|
|
|
|
bakhtawar wrote:
My target is to access data quickly and efficiently though accuracy can be compromised.
ummmmm u tend to get out exactly what u put in with these damn database things ... wish they could give us human storage devices huh?
"well i think the data you want is 3 but i could be wrong"
"... and so i said to him ... if it don't dance (or code) and you can't eat it either f**k it or throw it away"
sonork: 100.18128 8028finder.com
|
|
|
|
|
bakhtawar wrote:
My application is DOS based
DOS as in MSDOS app or DOS as in Console Application?
If it is a console application, look at some of the ADO articles available on this site.
Michael 
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
Hello!
I'm working on an application where a binary file must be loaded and should be kept in
memory during all execution. I guess that keeping data in physical memory and avoid memory swap on virtual memory is not possible.
Is it a way to keep the whole address space that concerns my application in physical
memory?
Thank you for any information !
Frédéric.
C++/MFC/SQL developer.
|
|
|
|
|
For NT-based systems, seems like <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/k106_8ble.asp">MmProbeAndLockPages<a> is the API you're after. For 95 and relatives, have a look at LinPageLock in the DDK documentation.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Hi All,
man, you know its Monday......
yes, i will lash myself after this.
i can't belive, i've gone brain numb on this. I need to trap wm_quit/wm_close or any systm messages that will cause my app to shutdown, so i can check if my app is ready to shutdown ,and prevent this from happening unless certain conditions are met in my app.
i've tried the OnCmdMsg --> if pMsg->message == WM_QUIT etc....
with no success.
is this suppose to go in the main app .cpp file or the mainfrm.cpp
Thanks in advance
lost, stupid and confused
Fred
|
|
|
|
|
if you override the OnClose() handler and simply return without executing the default handler if you don't want to close
"... and so i said to him ... if it don't dance (or code) and you can't eat it either f**k it or throw it away"
sonork: 100.18128 8028finder.com
|
|
|
|
|
|
If you are using the document/view architecture, look up CDocument::SaveModified() in MSDN.
|
|
|
|
|
|
WM_QUIT is not passed to any window proc (MFC or otherwise). When GetMessage() pulls a WM_QUIT out of the queue, it returns 0 to terminate the window's message loop.
--Mike--
Just released - RightClick-Encrypt v1.3 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Greetings, coders of the world. I've come because I'm quite at the end of my rope with an MFC bug, and need help. It's the most untraceable thing I've ever come across...
Anyway, I hope I can provide enough information about it (without giving the whole program's source away) to get a solution.
I'm using VC++ 6.0 (rather than .net because of compatibility issues), and have based my program off the MDI structure. Now, _sometimes_ when I create floating modal dialog boxes, the program locks up. It only happens when the dialogs are ownerless (parent = NULL), and when they're called with the DoModal() function. It appears to vary by dialog. For a while, anything I brought up was freezing. Since then (I don't know why) the standard About dialog and various custom settings windows have begun to work. Others still don't. One baffling thing is that I override the exact same methods in two dialogs (derived from CDialog, of course), and one works while the other doesn't. I implemented, as a test, a little message responder and had it try to call one, then another, in separate compiles. No difference in calling environments that I could spot, and still only one worked.
As we're all more than familiar with, there are many ways for things to not work. What baffles me is where this one shows up... in the middle of MFC's message loop. The dialog object construct fine, but when I call DoModal(), it locks up the message loop. Specifically, this callstack:
USER32! 77e1325c()
CWinThread::PumpMessage() line 814 + 19 bytes
CWnd::RunModalLoop(unsigned long 4) line 3478 + 19 bytes
CDialog::DoModal() line 536 + 12 bytes
This is the culprit line in PumpMessage():
if (!::GetMessage(&m_msgCur, NULL, NULL, NULL))
and the program screeches to a halt (strangely) right on this assembler instruction in USER32:
ret 10h
Obviously, this doesn't help much. I can't figure out what I did elsewhere in my program that would cause the message loop to break like that. I did have a fairly large OpenGL section that messed with windows pretty heavily, but that wasn't the culprit. At first, I wrote routines that would completely shut down the OpenGL windows' message pumps whenever a modal dialog was called. It was ugly, but it worked... or so I thought. Since then, it's popped up again with different dialogs, and after ripping out the 3D system altogether (well, commenting out) to try to isolate this bug, still no change.
One last thing that might be helpful. I stepped through my dialog routines from DoModal(), but couldn't tell specifically where in the construction/display cycle the error occurred. The message loop appears to run fine for a while, but stops before the windows get around to calling PreCreateWindow().
The CDC thanks you in advance for any help you can provide.
-Christian Miller
|
|
|
|
|
I think I remember seeing somewhere that there are special message-loop considerations when using OpenGL with MFC. I'm sorry I can't be more specific, but I saw it this weekend somwehere.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
Okay, so it's a big bug. I squelched the OGL portion of my app, same problem. I did manage to find a program source that manages MDI OpenGL windows nicely, but there are two big 'ol problems with it:
A) It's slow.
B) It's 18000+ lines.
Not exactly ideal, especially considering the time constraints I'm under. Any other ideas?
|
|
|
|
|
Greetings, coders of the world. I've come because I'm quite at the end of my rope with an MFC bug, and need help. It's the most untraceable thing I've ever come across...
Anyway, I hope I can provide enough information about it (without giving the whole program's source away) to get a solution.
I'm using VC++ 6.0 (rather than .net because of compatibility issues), and have based my program off the MDI structure. Now, _sometimes_ when I create floating modal dialog boxes, the program locks up. It only happens when the dialogs are ownerless (parent = NULL), and when they're called with the DoModal() function. It appears to vary by dialog. For a while, anything I brought up was freezing. Since then (I don't know why) the standard About dialog and various custom settings windows have begun to work. Others still don't. One baffling thing is that I override the exact same methods in two dialogs (derived from CDialog, of course), and one works while the other doesn't. I implemented, as a test, a little message responder and had it try to call one, then another, in separate compiles. No difference in calling environments that I could spot, and still only one worked.
As we're all more than familiar with, there are many ways for things to not work. What baffles me is where this one shows up... in the middle of MFC's message loop. The dialog object construct fine, but when I call DoModal(), it locks up the message loop. Specifically, this callstack:
USER32! 77e1325c()
CWinThread::PumpMessage() line 814 + 19 bytes
CWnd::RunModalLoop(unsigned long 4) line 3478 + 19 bytes
CDialog::DoModal() line 536 + 12 bytes
This is the culprit line in PumpMessage():
if (!::GetMessage(&m_msgCur, NULL, NULL, NULL))
and the program screeches to a halt (strangely) right on this assembler instruction in USER32:
ret 10h
Obviously, this doesn't help much. I can't figure out what I did elsewhere in my program that would cause the message loop to break like that. I did have a fairly large OpenGL section that messed with windows pretty heavily, but that wasn't the culprit. At first, I wrote routines that would completely shut down the OpenGL windows' message pumps whenever a modal dialog was called. It was ugly, but it worked... or so I thought. Since then, it's popped up again with different dialogs, and after ripping out the 3D system altogether (well, commenting out) to try to isolate this bug, still no change.
One last thing that might be helpful. I stepped through my dialog routines from DoModal(), but couldn't tell specifically where in the construction/display cycle the error occurred. The message loop appears to run fine for a while, but stops before the windows get around to calling PreCreateWindow().
The CDC thanks you in advance for any help you can provide.
-Christian Miller
|
|
|
|
|
No text here, move along.
|
|
|
|
|
Hello friends,
on the bottom (z-axis) i have a CView (Fullscreen), he create a CDialog (Fullscreen), and then he (the CView) create a CDialog (quarder-screen, bottom, y-axis).
I would like to operate with the Fullscreen-dialog and the quarder-screen-dialog. I can operate with the fullscreen-dialog, but not with the quarder-screen-dialog.
At the creation of the dialogs i use this:
ASSERT(m_DlgPFkt3Zeile->SetWindowPos(NULL
, a
, b
, c
, d
, SWP_HIDEWINDOW | SWP_NOACTIVATE | SWP_NOZORDER));
I have try all parameters of SetWindowPos, but with nothing parameter i can operate with the fullscreen-dialog and the quarder-screen-dialog.
Why i don't can operate with the quarder-screen-dialog?
Thank you for your help!
PS: Sorry for my bad english.
|
|
|
|
|
This doesn't solve your z-order problems, but you should replace ASSERT with VERIFY.
Tomasz Sowinski -- http://www.shooltz.com
- It's for protection
- Protection from what? Zee Germans?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
