I have added a new page to the wiki with some VGUI2 programming best
practices to follow:
http://developer.valvesoftware.com/wiki/VGUI2_Programming_Best_Practices
- Alfred
Alfred Reynolds wrote:
>>> OnThink() would work as well. You can use the ::OnTick() function by
> making the ivgui()->AddTickSignal( GetVPanel() ) to subscribe your
> panel
> to tick events. The AddTickSignal() lets you optionally choose the
> tick
> interval (rather than just once per frame) which can be a useful
> feature.
>
> Just make the label large enough to contain any text it could
> potentially display rather than dynamically resizing it (or use the
>>> SizeToContents() function if you really need to resize it).
>
> - Alfred
>
> Benjamin Davison wrote:
>> --
>> [ Picked text/plain from multipart/alternative ]
>> Thanks for the tip, but I implemented your sizeof(); suggestion :) It
>> ain't crashing anymore, but it's not displaying text weirdly enough.
>> Debug is still working :E
>>
>> Well anyway I'll be rewriting it anyway :D I'm thinking of how I am
>> gonna do that. Do you think using an ::OnThink() function like most
>> hud elements use would be the best way? Possibly in the OnThink();
>> Check if pRules->foo has changed. If it has call a function to
>> change the size and text of the label?
>>
>> And ::OnTick() There are only a couple of examples around the SDK
>> and I was trying to find the base function and I came across this in
>> vgui_BasePanel.cpp and found this:
>>
>> void CBasePanel::OnTick( void )
>> {
>> // Nothing
>> }
>>
>> How is this function called within the engine? And what is it good
>> for?
>>
>> On 3/30/06, Alfred Reynolds <[EMAIL PROTECTED]> wrote:
>>>
>>> Debug mode has a lot more padding between memory allocations
>>> typically. This call: vgui::localize()->ConvertANSIToUnicode(
>>> sString, unicode, 1024)
>>>
>>> Would cause a random piece of memory 512 bytes beyond the end of
>>> "unicode" to be zero to 0 (null terminating the unicode string). In
>>> debug you were probably zeroing unused memory so it had no impact,
>>> in release you were smashing the stack or the like causing a crash.
>>> Moral is, use sizeof(<variable>) when passing in buffer length
>>> parameters, never hard code them :)
>>>
>>> - Alfred
>>>
>>> Benjamin Davison wrote:
>>>> --
>>>> [ Picked text/plain from multipart/alternative ]
>>>> Thanks Jay, I'll take those pointers away(rim shot) when I rewrite
>>>> it in accordance with Alfred's suggestions.
>>>>
>>>> Still confusing that it worked in debug mode but displayed nothing
>>>> in release mode.
>>>>
>>>> On 3/30/06, Jay Stelly <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>> Actually looking at the code you're using, you probably should
>>>>> just skip string_t entirely (since the unicode conversion takes a
>>>>> char * anyway):
>>>>>
>>>>> const char *pString = "";
>>>>>
>>>>> then replace sString with pString...
>>>>>
>>>>> Jay
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [EMAIL PROTECTED]
>>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of Jay
>>>>>> Stelly Sent: Thursday, March 30, 2006 11:02 AM
>>>>>> To: [email protected]
>>>>>> Subject: RE: [hlcoders] Works in debug mode, does not it release
>>>>>> mode.
>>>>>>
>>>>>> Unless someone has defined a valid assignment or conversion
>>>>>> path for this that I don't normally use you have to do this
>>>>>> to your constant
>>>>>> strings:
>>>>>>
>>>>>>> sString = MAKE_STRING("Find the case!");
>>>>>>
>>>>>> at least that's why MAKE_STRING exists in the first place.
>>>>>>
>>>>>> It's not surprising that ConvertANSIToUnicode() would crash
>>>>>> if these assignments were producing an invalid pointer.
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: [EMAIL PROTECTED]
>>>>>>> [mailto:[EMAIL PROTECTED] On Behalf Of
>>>>>>> Benjamin Davison Sent: Thursday, March 30, 2006 10:50 AM
>>>>>>> To: [email protected]
>>>>>>> Subject: [hlcoders] Works in debug mode, does not it release
>>>>>>> mode.
>>>>>>>
>>>>>>> --
>>>>>>> [ Picked text/plain from multipart/alternative ] Very weird
>>>>>>> indeed, I'm working on some VGUI code and for some reason it
>>>>>>> works in debug mode with the IDE attatched and fails to work in
>>>>>>> release mode, and for the life of me I am stumped for a
>>>>>>> soloution. Here is some code to see if you guys have run into
>>>>>>> this problem.
>>>>>>>
>>>>>>> void CBBHudTaskList::Paint( void )
>>>>>>> {
>>>>>>> // getting a pointer to the game rules
>>>>>>> CHL2MPRules *pRules = HL2MPRules();
>>>>>>> if ( !pRules )
>>>>>>> return;
>>>>>>> // local player
>>>>>>> C_BasePlayer *pPlayer = C_BasePlayer::GetLocalPlayer();
>>>>>>> if ( !pPlayer ) return;
>>>>>>>
>>>>>>> string_t sString = "";
>>>>>>> wchar_t unicode[256];
>>>>>>>
>>>>>>> int x, y;
>>>>>>> int textSizeWide, textSizeTall;
>>>>>>> int iShown = 0; // number of lines shown
>>>>>>> int fontTall = vgui::surface()->GetFontTall( m_hLargeFont
>>>>>>> ); int border = 20;
>>>>>>>
>>>>>>> x = border / 2; // ScreenWidth() - border - textSizeWide;
>>>>>>> y = iShown * fontTall; // border + iShown * fontTall;
>>>>>>>
>>>>>>> SetSize( 300 + border, 40 );
>>>>>>>
>>>>>>>
>>>>>>> if (pRules->m_bCaptureObjectActive == true)
>>>>>>> {
>>>>>>> sString = "Find the case!";
>>>>>>> }
>>>>>>> else if (pRules->m_bCaptureZoneActivated == true) {
>>>>>>> sString = "Get to this location and do something";
>>>>>>> } else { sString = "No mission selected!";
>>>>>>> }
>>>>>>>
>>>>>>> vgui::localize()->ConvertANSIToUnicode( sString, unicode,
>>>>>>> 256);
>>>>>>>
>>>>>>> // --- Set up default font and get character height for line
>>>>>>> spacing vgui::surface()->DrawSetTextFont( m_hLargeFont );
>>>>>>> //vgui::surface()->DrawSetTextFont( m_hLargeFont );
>>>>>>> vgui::surface()->DrawSetTextPos(x, y);
>>>>>>> vgui::surface()->DrawPrintText( unicode, wcslen(unicode) );
>>>>>>> // print text
>>>>>>>
>>>>>>> BaseClass::Paint();
>>>>>>> }
>>>>>>>
>>>>>>> Now for some reason vgui::localize()->ConvertANSIToUnicode(
>>>>>>> sString, unicode, 256); was crashing the release mode(not the
>>>>>>> debug) if I put the buffer to 1024
>>>>>>>
>>>>>>> Have any of you guys run into this problem? Or can you see some
>>>>>>> error I have overlooked?
>>>>>>>
>>>>>>> --
>>>>>>> - Benjamin Davison
>>>>>>> --
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>>>> archives, please visit:
>>>>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>>> archives, please visit:
>>>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> To unsubscribe, edit your list preferences, or view the list
>>>>> archives, please visit:
>>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> - Benjamin Davison
>>>> --
>>>>
>>>> _______________________________________________
>>>> To unsubscribe, edit your list preferences, or view the list
>>>> archives, please visit:
>>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>> _______________________________________________
>>> To unsubscribe, edit your list preferences, or view the list
>>> archives, please visit:
>>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>>>
>>>
>>
>>
>> --
>> - Benjamin Davison
>> --
>>
>> _______________________________________________
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> http://list.valvesoftware.com/mailman/listinfo/hlcoders
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list
> archives, please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
