C / C++ / MFC

7-May-04 3:29

I am running a VC++ MFC based application using Visual Studio .NET, as it starts up it loads most of it's DLLs & then freezes so it never really starts the application it stays in this frozen state. The only way out of it is by killing it. I rebooted my machine, plus rebuilt my application but it didn't work.
What can be causing this to happen?

Jens Doose7-May-04 3:31

7-May-04 3:31

Sounds a little bit like a virus scanner or a firewall..

Jens

Member 5343577-May-04 4:05

7-May-04 4:05

Thanks but that's not the case here, could it be some static initialization that's a bit corrupted? just a guess

Jens Doose7-May-04 4:09

7-May-04 4:09

Well, maybe, but not very likely?!?

Is this the case with EVERY application or just with one specific app?

Jens

Member 5343577-May-04 4:53

7-May-04 4:53

just this one specific app

Jens Doose9-May-04 23:19

9-May-04 23:19

Try to isolate the problem.
If you're loading special DLLs add them one by one
to a new "dummy" project until it happens to this
app also.

Jens

Member 53435710-May-04 2:46

10-May-04 2:46

It's not the DLL, the DLL where it's freezing at, seems to load fine, it seems only to be happening on my machine, my co workers are able to run the same application just fine. What could have happened? I did a repair/reinstall on my VS but it didn't help.

basementman7-May-04 4:47

basementman

7-May-04 4:47

Does this happen only during a ShellExec type call where you double click on a file whose associated program is the one hanging?

onwards and upwards...

Member 5343577-May-04 4:52

7-May-04 4:52

it happens when I run it from the Visual Studio. NET in debug mode.

Problem with Scroll Bar

Azghar Hussain7-May-04 3:18

Azghar Hussain

7-May-04 3:18

Hi Guys,
I have little problem with the scroll bars. I have Displayed the bitmap on the DialogBOx. I want to Scroll bars to available depending on the dimensions of scroll bar. Problem is I am not able to calculate what to keep the Page size. I tired to keep the width and height as Scroll bar Range. But still Page size is nor properly set. Its giving flickering like problem to me.
Please can any one tell me how to calculate the scroll bars page size depending on the range.
bbye
"Thanks in Advance" Confused | :confused:

Unicode Listbox

Demian Panello7-May-04 3:12

Demian Panello

7-May-04 3:12

Hi.

I have problems with the ListBox control, (class CListBox), 'cause I have a Access 2000 database with text in russian. When I show the data in an EditBox or even in a Button, everything work fine, but when I want to show the data in a ListBox, it shows something like "??????????" or "|||||||".
The listbox have not UNICODE support?.
I think that the problem is with the method AddString() maybe it convert the text to ANSI.

What is the solution?. There's is an alternative listbox?

Thank you.

Demian.

Jens Doose7-May-04 3:17

7-May-04 3:17

Send a message to the ListBox directly and use
SendMessageW. Then it will interpret LPARAM/WPARAM
as unicode parameters.

Jens

Demian Panello7-May-04 3:57

Demian Panello

7-May-04 3:57

Hi!

Thank you for your answer.

I have write something like that

<br />
::SendMessage(m_lstText.GetSafeHwnd(), LB_ADDSTRING, 0, (LPARAM)(LPCTSTR) field);

And I have the same problem, the listbox can't show the info.

field is a CString variable, that one line before is asigned to an editbox that shows well the text in russian. At the beginning of the procedure the variable field was filled with the field of the database.
I dont know what I doing wrong.

Thank you very much for your support.

Demian.

Jens Doose7-May-04 4:04

7-May-04 4:04

Hi Demian,

Do you compile your app with UNICODE support?
If no, then you cannot use CString because it will
internally use ANSI characters.

Jens

Demian Panello7-May-04 5:03

Demian Panello

7-May-04 5:03

Yes the application is support UNICODE.
Remember that I can see the data in the editbox.

Demian.

Jens Doose10-May-04 0:08

10-May-04 0:08

I compiled a small sample app.
And RChin got the trick right from the beginning.
The font is the problem.
A ListBox uses the MS Sans Serif font, which obviously does not support Unicode.

Set the font to a different type, the it will work, like the following MFC sample code:

<br />
<br />
  CFont *pFont = m_ctrlList.GetFont();<br />
  LOGFONT lf = {0};<br />
  pFont->GetLogFont( &lf );<br />
  ::lstrcpyn( lf.lfFaceName, _T("Tahoma"), sizeof( lf.lfFaceName ) / sizeof( lf.lfFaceName[ 0 ] ) );<br />
<br />
  m_font.CreateFontIndirect( &lf );<br />
  m_ctrlList.SetFont( &m_font );<br />
<br />

That should do the trick...

Jens

RChin7-May-04 3:24

RChin

7-May-04 3:24

In addition to the comment above^, ensure that the font used by the listbox for display supports your russian UNICODE characters.

I Dream of Absolute Zero

The future of VC and MFC

joooooooe7-May-04 2:32

joooooooe

7-May-04 2:32

hello every body

what is the future of vc
ive read that microsoft wants everybody to move over to managed code

what is managed code
is this the end of vc

joooooooe

Confused | :confused:

toxcct7-May-04 2:35

toxcct

7-May-04 2:35

is it because code is going to be managed that VC is going to stop ? never !

second thing, every thing can't be managed... watch this

TOXCCT >>> GEII power

Navin7-May-04 2:52

Navin

7-May-04 2:52

Oh, I think VC will still be around. But to take advantage of newer OS features, probablly you'll have to use Managed C++ or some other .NET language. MFC, in my opinion, is headed towards maintenance mode. It will probably always work and compile, but I don't expect, say, all the new Longhorn stuff to be wrapped in MFC.

Unmanaged code will still be necessary, but it will be mostly for specialized functions and for backwards compatibility.

All that "managed" code is, is code that runs within the CLR framework. It is garbage-collected, can access the .NET runtime, etc.

"Fish and guests stink in three days." - Benjamin Franlkin

jmkhael7-May-04 3:06

jmkhael

7-May-04 3:06

While you speak, developpers are using C/C++ .NET and even assembly

If a new language is born doesnt mean that the old ones die.

Papa

while (TRUE)
Papa.WillLove ( Bebe ) ;

Nitron7-May-04 8:31

Nitron

7-May-04 8:31

Papa wrote:
If a new language is born doesnt mean that the old ones die.

I know, I work with people still adamant about using FORTRAN Dead | X|

...hey, at least there's no ADA code laying around in my environment Roll eyes | :rolleyes:

~Nitron.

ññòòïðïðB A start

RChin7-May-04 3:31

RChin

7-May-04 3:31

I agree with navin's comment regarding MFC.
I have used, am using and will use the MFC for a long while to come, but I can see a point in the distant future where it may fall out of popularity with the programming masses as new development fads takes over.

Regarding VC++, I don't think you have anything to worry about. As far as I'm concerned, VC++ will always be around (OK, maybe not always, but for a loooong time). The libraries in use may vary from MFC, ATL, WTL or the .NET malarky, but the language itself will survive. Vive VC++!

I Dream of Absolute Zero