|
Can anyone tell me how to REMOVE the buttons from a tabctrl ? Is this even possible ?? I've placed a WTL::CTabCtrl on my dialog with 3 pages inserted, I don't want the tab buttons at the top displayed, I will do the tab flipping in my code.
I looked into using the WTL::CPropertySheet but it won't work for my purposes ... although ... if I can't get ride of the tab buttons I may have to look at it again.
Thanks in advance for any help
Derrick Flannigan
Software Developer
|
|
|
|
|
Maybe I'm but without the tabs there's nothing left.
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
The 'tabs' are still there I just don't want the tab buttons that get displayed at the top of the control ... I know it seems odd I'm thinking it would be the easiest way to flip between 2-3 pages (or panes) of controls contained in a groupbox ....
D
|
|
|
|
|
It sounds like you're expecting the tab control to show/hide controls when you switch tabs, but that's not how it works. All the tab control gives you is the tabs, you still have to handle switching panes/pages/whatever you have in response to the user changing tabs. So even if there were a tabless tab control, it wouldn't save you any work.
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
I think I've seen code somewhere that does this, but I need to be able to determine for a locked file what the owning process is. It would be even better if I could get a human readble representation of the process, but I'm willing to start at the beginning . This needs to work on 98/NT/2000. Thanks for any suggestions.
|
|
|
|
|
Hi
I want to learn programming with directX
so if anyone can recommend some resources
I Know nothing about directX programming
MR.Byte
|
|
|
|
|
try www.gamedev.net
or better http://nexe.gamedev.net
|
|
|
|
|
Any other resources !
MR.Byte
|
|
|
|
|
http://www.wazooenterprises.com is pretty good as well I've found..
|
|
|
|
|
Thanks
MR.Byte
|
|
|
|
|
I may be confusing my memory leak with a resource leak. In any case,
what is happening is that I have setup CRect’s within my dialog window
as the actual areas that I’ll be bltting to.
The program seems to work fine for awhile, however, after
executing the program 20-30 times (opening and closing the app), the
areas (CRects) that had once successfully been bltted, do not show
anything anymore, but only the default gray background. …only rebooting
solves problem. A sign of leakage somewhere?
Another difference I’ve been noticing is that I did my initialization
inside my InitDialog() function and not OnCreate(). Important? I don’t
know…
Here’s some of my initialization code:
CRect rectDialog;
GetClientRect(&rectDialog);
rectDialog.NormalizeRect();
m_rectZoom.SetRect(rectDialog.left + 250,
rectDialog.top + 50,
rectDialog.left + 700,
rectDialog.top + 500);
m_rectZoom.NormalizeRect();
m_rectHead0.SetRect(rectDialog.left + 50,
rectDialog.top + 100,
rectDialog.left + 200,
rectDialog.top + 250);
m_rectHead0.NormalizeRect();
m_rectHead0Source.SetRect(0,0,2000,2000);
m_rectHead0Source.NormalizeRect();
m_rectZoomSource.SetRect(0,0,2000,2000);
m_rectZoomSource.NormalizeRect();
pDC = this->GetDC();
m_dcHead0 = new CMemDC(pDC, m_rectHead0Source);
this->ReleaseDC(pDC);
Of course I left a lot of my code out, but hopefully this may give you
an idea of where I’m at. My OnPaint() got somwhat complicated, so I’ll
try to paraphrase…
On the first call of OnPaint() I draw an ellipse to m_dcHead0 and
StretchBlt that to my paintDC (a’la the pointer returned by BeginPaint
(&PAINTSTRUCT) ). Depending on where my mouse is clicked, I StretchBlt a
portion of m_dcHead0 to the m_dcZoom.
That’s really making a long story short. Please don’t break your back
looking over my code. I was just hoping for some quick ideas, I’d
rather not have you finish my work. Your help has been much appreciated.
-t²
>Oh - ok - I make a distiction between resource leaks and memory leaks - >perhaps what you have is a resource leak.
>
>If you are working with classes derived from CGdiObject (like CBrush, >CPen) the ~CGdiObject destructor should free the resource for you - so >when the testBrush goes out of scope, or its containing class is >destroyed, you should be ok. MFC will ASSERT in debug mode if you try >to call CreateBrush or CreatePen twice without calling DeleteObject.
>
>If you are working with handles returned from say, a call >to ::CreateBrushIndirect (not using CBrush) you must be careful to >destroy the object (after deselecting it from the DC).
>
>What is telling you that you have the leak? - I thought it was a dump >provided by the debug C runtime allocation routines - in which case the >allocation number would be the one in curly braces.
>
>Say - since this thread is getting kind of buried now, why don't you >post a bit of code (showing your SaveDC and RestoreDC calls and stuff >that you are doing in between) in a new thread - rem - use
and >
to surround your code - if its a resource leak, it may not be >obvious - I seem to recall some subtle gotchas that have appeared in >these posts - but I bet you'll get a helpful answer real quick.
|
|
|
|
|
A sign of leakage somewhere?
Sure. First thing to check: OnPaint. Are you sure your GDI objects (CPen, CBrush etc) are not selected into any device context when they are going out of scope? If MFC destructor calls ::DeleteObject, it will fails when object is selected.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I'm trying to cover my tracks and for every function that
draws to some CDC I do do a SaveDC and RestoreDC before actually
selecting any GDI Objects into it. But I'll double check to see
if something slipped by me.
Much Thx,
-t²
|
|
|
|
|
Also check device contexts being destroyed - this also applies to memory DCs.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
BeginPaint(&PAINTSTRUCT) and EndPaint(&PAINTSTRUCT) should cover
that right?
This isn't my whole OnPaint() function, but it should cover important
issues.
PAINTSTRUCT ps;
CPaintDC *paintDC;
paintDC = (CPaintDC *)this->BeginPaint(&ps);
paintDC->StretchBlt(m_rectHead0.left, m_rectHead0.top,
m_rectHead0.Width(), m_rectHead0.Height(),
m_dcHead0,
m_rectHead0Source.left, m_rectHead0Source.top,
m_rectHead0Source.Width(), m_rectHead0Source.Height(),
SRCCOPY);
this->EndPaint(&ps);
-t²
|
|
|
|
|
You don't need this SDK-style stuff. I'm not sure if this has something to do with your problems, but you can just declare CPaintDC and use it inside OnPaint. No need to play with BeginPaint and EndPaint; CPainDC does this for you.
Also, you don't need to use this->GetDC and this->ReleaseDC. Just declare a CClientDC variable.
And why on earth are you using 'this->'? Do you come from JavaLand?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I've created an ATL COM - dll - MFC Supported with the AppWizard and I added a function that return a CString.
Now I want access to this function from another application to do it I type the next code.
In the ATL COM
...
__declspec(dllexport) CString GetEncodedText(CString p_sPlainText);
...
In the other application
...
hDLL = AfxLoadLibrary("BabMD5.dll");
if (hDLL != NULL) {
typedef CString (CALLBACK *ENCODETEXT)(CString);
ENCODETEXT p_encodeText = (ENCODETEXT)GetProcAddress( hDLL, _T("GetEncodedText"));
if ( p_encodeText != NULL) { // -> NEVER GET HERE
strEncoded = (*p_encodeText)( strPlain );
}
AfxFreeLibrary( hDLL);
}
...
Anybody knows what's happen? Why I can't get the function?
Thanks in advance
|
|
|
|
|
Why are you using a C export function in a COM DLL? It would make more sense to create an interface which has GetEncodedText as a method.
HRESULT CTest::GetEncodedText(BSTR PlainText, BSTR* EncodeText)
Michael
|
|
|
|
|
You are right, but this is my first adventure with COM and then I don't know how to access to the method through the other application
|
|
|
|
|
If you wrote a ATL/COM Object, Only you need to Import the Dll functions...
Cheers!!!
Carlos Antollini.
|
|
|
|
|
Don't mix standard DLL exports with In-Proc (DLL) COM Servers.
It won't work !!!!
|
|
|
|
|
The source code shown below is a simple, working wav file player application. The program work perfectly under Windows 2000, but fails in a repeatable fashion under Windows 98.
Let me briefly describe the functionality, then describe a mode of operation that works properly under both OS'es, then a mode of operation that fails only under Windows 98.
When the program is started, the wav memory structures are initialized (WM_CREATE calls CreatePlayer). When a file is to be played, Play() is called. This routine opens the file "test.wav" (a 44.1 kHz sampled, stereo file), prepares the headers and fills the first set of buffers. As the wav device renders each buffer, it send a MM_WOM_DONE message to its callback routine. This routine sends a WM_COMMAND message to the main program, which then calls ReadBuffer() to refill the just-emptied buffer. When there is no more data to be read from the file, ReadBuffer() returns a 1, signaling the main program that the file has been completely rendered. The main program then sends a Stop(), which closes the wav device. Note that Stop() does not free any memory as Play() can be called again.
Under both OS'es, if the a file is Play()'ed then Stop()'ed, it can be Play()'ed again without any problems. This is as expected.
Under Win2k, if a file is allowed to Play() to completion, clicking Play() again causes the file to be Play()'ed. This is as expected. However, under Win98, when a file is allowed to Play() to completion, clicking Play() results in waveOutPrepareHeader() returning with an error, MMSYSERR_NOMEM, and the file does not Play().
I have tried a number of ways to solve this problem, including using memory locking, freeing and reallocating memory each time the player Stop()'s, etc. I haven't a clue as to why this is failing in this manner. Your thoughts and suggestions are gratefully accepted!
=== source code ===
#include <windows.h>
#include <winuser.h>
#include <mmsystem.h>
#include <stdio.h>
#define NBUFS_OUT 4L
#define OUTBUFSIZE 0x4000L
#define ID_DONEBUFFER 40000
#define ID_CLOSED 40001
#define ID_PLAY_BUT 40002
#define ID_STOP_BUT 40003
#define WAVE_PLAYING 1
#define WAVE_READY 2
long doneBufCnt = 0;
FILE *fp = NULL;
HWND hWnd = NULL;
HWAVEOUT hWaveOutDevice;
WAVEFORMATEX waveOutFormatEx;
WAVEHDR waveOutHdrs[NBUFS_OUT];
HINSTANCE myhInstance;
///////////////////////////////////////////////////////////////////////////////
void CALLBACK WaveOutCallback (HWAVEOUT hwo, UINT uMsg, DWORD dwInstance, DWORD dwParam1, DWORD dwParam2)
///////////////////////////////////////////////////////////////////////////////
{
switch (uMsg)
{
case MM_WOM_OPEN: // device opened via waveOutOpen(), nothing to do
break;
case MM_WOM_DONE: // device done playing data sent via waveOutWrite()
SendNotifyMessage (hWnd, WM_COMMAND, ID_DONEBUFFER, ((WAVEHDR *)dwParam1)->dwUser);
break;
case MM_WOM_CLOSE: // device closed via waveOutClose()
SendNotifyMessage (hWnd, WM_COMMAND, ID_CLOSED, 0L);
break;
}
}
///////////////////////////////////////////////////////////////////////////////
long ReadBuffer (long curBuf)
///////////////////////////////////////////////////////////////////////////////
{
if ((waveOutHdrs[curBuf].dwBufferLength = fread (waveOutHdrs[curBuf].lpData, 1, OUTBUFSIZE, fp)) != OUTBUFSIZE)
{
if (feof (fp))
doneBufCnt++;
}
else
waveOutWrite (hWaveOutDevice, &waveOutHdrs[curBuf], sizeof (WAVEHDR));
if (doneBufCnt == NBUFS_OUT)
{
doneBufCnt = 0;
return 1;
}
return 0;
}
///////////////////////////////////////////////////////////////////////////////
void CreatePlayer (void)
///////////////////////////////////////////////////////////////////////////////
{
long myInt;
fp = fopen ("test.wav", "rb");
waveOutFormatEx.wFormatTag = WAVE_FORMAT_PCM;
waveOutFormatEx.nChannels = 2;
waveOutFormatEx.nSamplesPerSec = 44100;
waveOutFormatEx.nAvgBytesPerSec = 176400;
waveOutFormatEx.nBlockAlign = 4;
waveOutFormatEx.wBitsPerSample = 16;
waveOutFormatEx.cbSize = (WORD)0;
for (myInt = 0; myInt < NBUFS_OUT; ++myInt) {
memset (&waveOutHdrs[myInt], 0, sizeof (WAVEHDR));
waveOutHdrs[myInt].lpData = (char *)calloc (OUTBUFSIZE, sizeof(char));
waveOutHdrs[myInt].dwUser = myInt;
waveOutHdrs[myInt].dwBufferLength = OUTBUFSIZE;
}
}
/////////////////////////////////////////////////////////////////////////
void Play (void)
///////////////////////////////////////////////////////////////////////////////
{
long myInt;
DWORD dwInstance = 0;
fseek (fp, 44, SEEK_SET);
waveOutOpen ((LPHWAVEOUT)&hWaveOutDevice, WAVE_MAPPER, &waveOutFormatEx, (DWORD)WaveOutCallback, dwInstance, CALLBACK_FUNCTION);
waveOutPause (hWaveOutDevice);
for (myInt=0; myInt
|
|
|
|
|
Is there a better (faster) way to load/reload/refresh a report type of CList than looping the Recordset and adding the items. When the recordset is large, it seems to take a long time to fill the CList.
Here's what I'm doing now:
m_pSet->MoveFirst();
while (!m_pSet->IsEOF)
{
Add Items to the CList here
}
m_pSet->MoveNext();
Thanks!
Richard
|
|
|
|
|
How many items are you putting into the CListCtrl? Too many and CListCtrl does slow down. Does it make any difference if you load the data into a collection class first and fill the listctrl from the collection?
Michael
|
|
|
|
|
C'mon Michael - do you really think that putting data into std::something or CxxxArray first, then copying everything into CListCtrl will help?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|