--
[ 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 ru
The third arg to ConvertANSIToUnicode() is the size of the output buffer
in bytes. In this case you should use sizeof(unicode).
This kind of code is the wrong pattern for VGUI2. It will perform really
badly (because of the expensive operations you are running every time
you paint) and makes your l
rs@list.valvesoftware.com
> 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
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly
> Sent: Thursday, March 30, 2006 11:02 AM
> To: hlcoders@list.valvesoftware.com
> Subject: RE: [hlcoders] Works in debug mode, does not it release mode.
>
> Unless someone has defined a valid assignment or conversion
> path for thi
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:5
;
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Jay Stelly
> > Sent: Thursday, March 30, 2006 11:02 AM
> > To: hlcoders@list.valvesoftware.com
> > Subject: RE: [hlcoders] Works in debug mode, does not it releas
ith pString...
>>
>> Jay
>>
>>
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Jay
>>> Stelly Sent: Thursday, March 30, 2006 11:02 AM
>>> To: hlcoders@list.valvesoftware.com
>
code conversion takes a char *
> >> anyway):
> >>
> >> const char *pString = "";
> >>
> >> then replace sString with pString...
> >>
> >> Jay
> >>
> >>
> >>> -Original Message-
> >>>
;>
>>>> 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 = "";
>>>>
>&g
isplayed 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
nfusing 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 usi
Alfred Reynolds wrote:
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:
Does this burst of free time creativity mean that voice_speex and the
up
Its definitely sciving.
- Alfred
Matt Judge wrote:
> Alfred Reynolds wrote:
>
>> 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:
>>
--
[ Picked text/plain from multipart/alternative ]
Hey, I'm not an easy job :P
On 3/31/06, Alfred Reynolds <[EMAIL PROTECTED]> wrote:
>
> Its definitely sciving.
>
> - Alfred
>
> Matt Judge wrote:
> > Alfred Reynolds wrote:
> >
> >> I have added a new page to the wiki with some VGUI2 programming
Reviving an old thread of a month ago since I'm still not certain what
the implications are.
So exactly why is it better to avoid complex Paint() methods? Methinks
that eventually down the line, the vgui::ISurface calls are still being
made, so it would make little difference that it is being cal
It is a code maintainence, performance and reuse issue. If you roll your
own Paint() code you end up having to rewrite functionality in each
paint call and you tend to make your layout logic code rather than data
driven. Paint also gets called many times per second, it is easy to blow
away performa
On Fri, 2006-04-14 at 12:25 -0700, Alfred Reynolds wrote:
> It is a code maintainence, performance and reuse issue. If you roll your
> own Paint() code you end up having to rewrite functionality in each
> paint call and you tend to make your layout logic code rather than data
> driven. Paint also g
If you only call surface()->DrawTexturedRect() and the like in your
Paint() function it won't defeat any VGUI2 functionality, but you will
make your code hard to maintain. I would decompose the UI into the basic
components, right a class to support each widget you need, put them
together using a pa
18 matches
Mail list logo