|
CString is a MFC class, I don't think you can use CString parameters from VB or Fortran. Change your parameter to char*.
|
|
|
|
|
a) I would look on the MSDN CD's first. If you can't find it there, a decent advanced book about VB would probably have the info you need. Your DLL can use MFC (statically linked is my advice), but it cannot be an extension DLL (it must be a "regular" DLL). You also cannot use CStrings as parameters or return values.
b) I don't know anything about VB, so I can't answer that.
c) You might look into writing an ATL COM DLL. It's supposed to be much easier to use from disparate languages (assuming you can use a COM DLL from within your fortran app - if not, forget this option).
"...the staggering layers of obcenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
hi all,
I want to call a function in VB ActiveX DLL or Main Form which will be called back by a VC++ App, is it possible like ENUM thingies...
thanx in adv.
-Shrirang
[b_shrirang@hotmail.com]
|
|
|
|
|
Hi,
I was wondering if there's something like interrupts in a window application that I can use?? I mean a real interrupt (nothing to do with all the messages an application can get).
In my application which is always busy (openGL window which is constantly refreshed) I would like to be able to respond very quickly to some requests coming from another application (which should actualize (read, modify and write) about 100 values in the first application, and this many times a second)
How can I solve this problem in an elegant way??
Thanks
|
|
|
|
|
Use multiple threads. You can move the rendering code onto separate worker thread, as well as the code which is going to respond to the external requests. How do you communicate with other app?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Aahhhh, I think I understand now. Please correct me if I'm wrong:
An application with only one thread will never interrupt itself in the middle of a portion of code to execute another portion of the application's code.
An application with more than one thread can stop in the middle of a portion of code to execute another portion of code from the other threads.
Is this right? (of course windows can interrupt an application anytime to continue with another application)
So if I do it like you proposed it, I will use a second thread only to respond to other program's requests.
I communicate with other applications through a dll with a shared data segment. But I'm trying to use the "Postmessage" command.
Thanks for your advice
|
|
|
|
|
In my application which is always busy (openGL window which is constantly refreshed) I'd say this is design error #1.
Imagine an infinite fast machine. If you "constantly refreshed" the view (not the window) I'd say you have a bug in your program, since no program needs to update faster than the screen can update.
That said, are you really sure you need "interrupts"? Note that e.g. DirectX let you wait for vblank. Also note that current drivers (e.g. NVidia) spin-lock on these, giving no other part of the system a chance to "do its stuff", all to make 3D games look good in benchmarking (i.e. 300 FPS on a screen that still only do 85Hz).
/Mike
|
|
|
|
|
Ok, I understand. But if I don't have a lot more than 30 different frames per second, I think there's no wast of time. But your're right. It might be ok on my slow computer, but on others there would be a waste of computing time.
I know I'm not very good at programming...
Thanks
|
|
|
|
|
Ok, I understand.
Great! Now on to a possible solution.
If you have a batch of 100 variables to update every request (and you have pretty tight time demands) I'd go for mutextes and a memory mapped "file". One mutex signalling to the supplying application "Please provide data", the supplying app writes the data to the mempry mapped section and the signalling the other mutex "Done, go ahead and read the data". Without some _really_ fancy stuff this is AFAIK as fast as you can go using Win32.
++luck
/Mike
|
|
|
|
|
'scuse me for interrupting. Its just the 'communications' between your two halves.
In the Windows world I may be a naughty boy suggesting this. The thing is that I've been programming unix since the old queen died (god rest his soul) and used to have the same communicate-between-threads-especially-at-speed headaches until I discovered the joys of services. The nature of most of my programs (factory control stuff) is very modular, though not entirely independant.
I devised a packet system that all of my programs understand (to varrying degrees depending on their need), I stole a service port number and bounce messages off that.
I'm sure you Mr Freeze are able to understand how its done, but for the sake of others let me give a briefing on it.
//The packets. These are C structs but you can use classes just as
//well, or better, I just have to take into account programs I
//wrote
//a million years ago and have misplaced the source.
struct
{
UINT StructSize;
UINT DataSize;
/*Because i use a shared service number I need each program to
have an ID. So that others receiving the packets know if this is
one there need to listen to.*/
UINT ProgramID;
/*even if its the right progam, will I understand it? */
UINT ProgramVersion;
/* for real time apps time can be important. BETTERTIME is
just a 'union' of mine which holds time in a DWORD format as
well as being able to get at the elements in byte form.
(usefull for sorting and comparison)*/
BETTERTIME Time;
/*Command/Type of information contained. It does not need to
be globally understood, though for the sake of future
proofing I tend to make it unique across applications.
If this message isn't for this thread then we do not get
as far as checking this*/
UINT Command;
void* Data
};
Each program is able to be server or client. It starts by sending a Welcome message. If no one replies then it assumes the role of server.
As server it keeps a list of all clients that come online and reflects all messages to all clients. I also added the ability to pass this client information to 'prime' clients so that is a server is lost another can take over without much loss.
It can of cause be changed such that a dedicated server is present, but the orriginal point was that I wanted all threads/programs to be able to talk to all others. Also I didn't want to be in a situation where data is not collected because there is no server present.
As I said, its my first day on this list and I'm not certain yet what level of information to aim at. Though I got the impression from some I have read on this list that we can assume a decent level of programming skills.
We do it for the joy of seeing the users struggle.
|
|
|
|
|
Good afternoon or whatever..
I have a project going here, trying to learn the ins and outs of MFC and Visual C++. When I close my app, I can code state saving routines in the function I derive from CDocument::OnCloseDocument() and they seem to get called. What gets called when my program is running when the user goes to Shutdown and Windows shuts down? It doesn't seem to be OnCloseDocument.
In more specific terms.. I have a program sitting in the tray that will often be forgotten about and I want it to be able to save its state when the user shuts off his computer.
Thanks!
-Jason
|
|
|
|
|
Your main frame window's OnClose() will get called when system is being shut down...
Put your code there
Nish
|
|
|
|
|
|
The toolbar style CBRS_GRIPPER creates a little line to the right of a toolbar a create. The version of C++ I use has two of those gripper lines on all their toolbars. Anyone know the toolbar style to get that affect or how to get that affect if its not a style?
<marquee>Raffi
|
|
|
|
|
You mean when they float ? I ended up just drawing them myself.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
Unfortunately, CControlBar::DrawGripper is not virtual. It's called only from two places in MFC 6 - one of them is CControlBar::DoPaint, which is short and virtual. This one is easy to override with your own call to double-gripper drawing function.
Unfortunately, there's another non-virtual function which calls DrawGripper - CControlBar::EraseNonClient. You'd have to hunt down and replace all calls to EraseNonClient in your toolbar class.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
HI,
I am trying to write a small addition to a VC++ programme that will allow it to save the client area as a .BMP file. Is there a simple way of doing this (i.e one of the MFC's? or some simple code?). From all I have seen one has to convert DDB into DIB's but I cannot find a way to save this to disk.
Help greatly appreciated.
|
|
|
|
|
GetClientDC to get the Window, then a class like CXImage ( from Code Project ) to save the file.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
Hi,
I am trying to draw a grid onto a CView.
All is fine until i do a resize, the grid doesn't fit into the far right and lower bottom regions correctly. My suspicions are, its either some strange effect with rounding, or something strange with resize and repainting that i am oblivious to!
Anyway Heres my code.
void CTestView::OnPaint()
{
CPaintDC dc(this); // device context for painting
POINT line[2];
//Draw The Columns
for (int col=0; col <=m_cols; col++)
{
line[0].x = ScreenDimensions.Width() / m_cols * col;
line[0].y = 0;
line[1].x = ScreenDimensions.Width() / m_cols * col;
line[1].y = ScreenDimensions.Height();
dc.Polyline(line,2);
}
//Draw The Rows
for (int row=0; row <=m_rows; row++)
{
line[0].x = 0;
line[0].y = ScreenDimensions.Height() / 50 * row;
line[1].x = ScreenDimensions.Width() ;
line[1].y = ScreenDimensions.Height() / 50 * row;
dc.Polyline(line,2);
}
}
Cheers
Richard Jackson
|
|
|
|
|
What is ScreenDimensions ? You should just call GetClientRect to achieve this.
Given that you're drawing to the width and height of ScreenDimensions, and getting problems on the right/bottom, I'd say the problem is actually the value itself.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
Screen Dimenions is a GetClientRect, its's a truly bizzare effect, when you resize the view. At first i though it must be a rounding problem, but even that doesn't seem to make sense!
Thanks Again, Much Appreciated
Richard
|
|
|
|
|
When drawing into a window you usually have to use width+1 and height+1 when drawing with GDI functions. Most GDI functions will draw up to but not including the last pixel value.
Todd Smith
|
|
|
|
|
OK, I have created a HBITMAP using the LR_CREATEDIBSECTION Flag. I have then attached that to a CBitmap object. At this point, I believe I have loaded a Device Independant Bitmap. I can get this DIB to be drawn to the screen too, However, I need low-level access to the pixels underneath, I am trying to use GetDIBits, but the function keeps returning 0 (i.e. it hasn`t scanned any lines), I think its to do with the fact that I have used (HDC)pBitmapWnd->GetDC() to return a handle to the Device Context, because everything else is empty (VOID* lpVOID, and BITMAPINFO* lpINFO are initialized appropriately). The hbitmap structure is definately a valid one, any ideas on how to get this going. Also, once I`ve used GetDIBits how do I access the actual bits of the bitmap? Many thanks go to Graussy, who got me on the right track at last.
Thanks
AEGC
|
|
|
|
|
once you get GetDIBits to work (which i'm afraid i can't help you with, i hate that function ), you'll have a DIB. in general, getting to the pixels in a DIB is a non-trival matter, given the number of different ways a DIB can hold data. but, since you can tell GetDIBits which format to use when Getting the data, your job is easier.
i'd tell it to give a 32 or 24 bit true color DIB. that way you don't have to worry about palettes or bit masking.
see the MSDN for "BITMAPINFOHEADER" for info on how DIBs are formatted.
good luck
-c
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
This is the function I use to get access to the pixels of a HBITMAP . Maybe it'll suit your needs with minor modifications.
BOOL RetrievePixels(HDC hDC,HBITMAP hBitmap,
LPBYTE *ppBytes,
LPBITMAPINFO lpBmi)
{
BITMAPINFO bmi={{sizeof(BITMAPINFOHEADER),0,0,1,0,0,0,0,0,0,0}};
memcpy(lpBmi,&bmi,sizeof(bmi));
if(GetDIBits(hDC,hBitmap,0,0,NULL,lpBmi,DIB_RGB_COLORS)==0){
return FALSE;
}
if((*ppBytes=(LPBYTE)malloc(
4*((lpBmi->bmiHeader.biWidth*3+3)/4)*lpBmi->bmiHeader.biHeight))==NULL){
return FALSE;
}
lpBmi->bmiHeader.biBitCount=24;
lpBmi->bmiHeader.biCompression=BI_RGB;
if(GetDIBits(hDC,hBitmap,0,lpBmi->bmiHeader.biHeight,*ppBytes,lpBmi,DIB_RGB_COLORS)==0){
return FALSE;
}
return TRUE;
}
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|