C / C++ / MFC

Re: SetSystemCursor in VC++

23-Jul-04 0:15

int InsertItem( int nItem, LPCTSTR lpszItem );

nItem is the index in the ListCtrl where your item gets if you insert, it sound like you have hardcoded it to 0.

to enter 1, 2, 3, 4 do

InsertItem(0, "1");
InsertItem(1, "2");
InsertItem(2, "3");
InsertItem(3, "4");

Arjan

Re: CListCtrl InsertItem

V.23-Jul-04 1:13

23-Jul-04 1:13

if I'm not mistaken AddString or something should add items at the bottom off the list. InsertItem will insert the item at a given position.

"If I don't see you in this world, I'll see you in the next one... and don't be late." ~ Jimi Hendrix

Re: CListCtrl InsertItem

David Crow23-Jul-04 9:34

David Crow

23-Jul-04 9:34

V. wrote:
if I'm not mistaken AddString...

... is a CListBox() method.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

SetSystemCursor in VC++

5iveboy22-Jul-04 21:56

5iveboy

22-Jul-04 21:56

hi,
I use SetSystemCursor to change the normal mouse cursor to something else, and 2 seconds later change it back to it's original. I can change the cursor the first time. but the second change does not happen until the first change is called once again. Please advise.
thanks a million Roll eyes | :rolleyes:

, see below.
ps. CopyCursor doesn't seem to work.

this is inside a function that is called every 4 seconds:

at the end of 1 second change mouse cursor from normal to appstarting

hCurCopy = LoadCursor(NULL, IDC_APPSTARTING);<br />
SetSystemCursor(hCurCopy,OCR_NORMAL);

later in the code
at the end of 3 seconds change cursor from appstaring to normal

hCurNorm = LoadCursor(NULL,IDC_ARROW);<br />
SetSystemCursor(hCurNorm,OCR_APPSTARTING)

erkanina22-Jul-04 22:17

erkanina

22-Jul-04 22:17

Use following codes

//... Set Your Cursor
SetCapture();
SetCursor(AfxGetApp()->LoadCursor(IDC_APPSTARTING));

//... Restore to old
ReleaseCapture();
SetCursor(AfxGetApp()->LoadCursor(IDC_ARROW));

My Program will not install on Windows NT 4

LittleYellowBird22-Jul-04 21:55

LittleYellowBird

22-Jul-04 21:55

I've just had an error reported by a customer saying that my VC++6 Program will not install on Windows NT 4. They say there is an 'error message concerning 6883 in the MFC42.DLL'.

Anyone seen this before? What can I do about it? We haven't got an NT machine to try it on so I am a bit stumped at the moment!

Any ideas?

Ali

Arjan Schouten23-Jul-04 0:04

23-Jul-04 0:04

The DLL on your customers machine is out of date, it can't export the function with ordinal 6883. Try supplying your customer with a newer DLL or beter yet, link your program statically so it won't need the customers DLL!

Arjan

LittleYellowBird23-Jul-04 2:33

LittleYellowBird

23-Jul-04 2:33

Thanks, for the help - sounds like one quuick fix and one more permanent fix. I've never considered linking any differently - I will look into it.

By the way, what are the pro's & con's of linking statically & dynamically?
Any problems I should look out for?

Thanks Again Smile | :)

Ali

Navin23-Jul-04 2:58

Navin

23-Jul-04 2:58

General rule of thumb - always link statically!

You have found the "con" of linking dynamically - if the libraries (MFC42.DLL and MSVCRT.DLL) are out of date on your customer system, then you'll have to redistribute them - and that is a royal pain.

The "con" of linking statically is that your executable will be a little bigger. It is also a little trickier if you call another MFC DLL and try to share memory/data between the two.

An expert is somebody who learns more and more about less and less, until he knows absolutely everything about nothing.

Bitmaps and the clipboard

David Crow23-Jul-04 9:49

David Crow

23-Jul-04 9:49

Alison Pentland wrote:
By the way, what are the pro's & con's of linking statically & dynamically?
Any problems I should look out for?

If you statically link code, it may require upgrades in other DLLs that could never be statically linked.

Also, if you have a DLL that is statically linked with MFC, and it is being used by an EXE that is dynamically linked with MFC, there will be troubles. In other words, if the EXE has already loaded MFC42.DLL, you will have
problems because your DLL is trying to load a second copy, and the two will
become confused. Alternatively, you will end up with whatever copy the
EXE has loaded.

See if this thread helps any.

"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen

tunerica22-Jul-04 20:02

tunerica

22-Jul-04 20:02

I have tried to use this article:
"All you ever wanted to know about the Clipboard..."
http://www.codeproject.com/clipboard/clipboard_faq.asp?df=100&forumid=137&select=881708#xx504274xx

and the infromation that it provides to retrieve a bitmap from the clipboard, and it doesn't seem to be working. When I run the debugger it seem that this call is the one that is not working:

HBITMAP handle = (HBITMAP)GetClipboardData(CF_BITMAP);

The debugger has the following listed for handle:

CXX0030: Error: Expression can not be evaluated.

Why is this? What has gone wrong? If anything, cause I may just not understand it.

Micheal

Problem with CTreeCtrl::DeleteAllItems

Stlan22-Jul-04 20:01

Stlan

22-Jul-04 20:01

I have a strange problem with CTreeCtrl::DeleteAllItems under VS2003: it seems impossible to insert a new tree item after having called this function.

Let's try a simple example:
- Create a new MFC dialog application,
- Add a tree control in the dialog,
- Associate a CTreeCtrl variable with it,
- in the OnInitDialog, add the code:

c_Tree.InsertItem(_T("Item before"));<br />
   c_Tree.DeleteAllItems();<br />
   c_Tree.InsertItem(_T("Item after"));

When executing the prg, the control remains empty. However, if I comment the call to DeleteAllItems, I see two items as expected. Dead | X|

Has anybody already experimented this ?

Arjan Schouten22-Jul-04 23:52

22-Jul-04 23:52

Just a quess but try adding a UpdateData(FALSE); after the last InsertItem

Arjan

Stlan23-Jul-04 0:27

Stlan

23-Jul-04 0:27

I doesn't change anything because UpdateData usually validates DDX data and not DDX controls.

However, insertions work perfectly as long as I do not use DeleteAllItems. As soon it is called, no further insertions are possible (ie. InsertItem returns a valid HTREEITEM handle, but the tree control client area remains empty, even if I force the control to redraw.)

Looks like DeleteAllItems makes a real mess in the control! Confused | :confused:

Arjan Schouten23-Jul-04 1:34

23-Jul-04 1:34

You're right this is a bug! But you can workaround it.

<br />
	m_cTree.InsertItem("Before");<br />
<br />
	m_cTree.SetRedraw(FALSE);<br />
	m_cTree.DeleteAllItems();<br />
	m_cTree.InsertItem("after");<br />
	m_cTree.SetRedraw(TRUE);<br />

or just set the tree's scroll property to true.

Arjan

Stlan23-Jul-04 1:46

Stlan

23-Jul-04 1:46

Thank you, Arjan for the workarounds!
Rose | [Rose]