Here is a strange behavior I've tried to isolate in a short
reproduction code but unsuccessfully.

So, sorry if I refer to a "long" code here:

http://groups.google.com/group/micro...e=source&hl=fr

See inside comments for "explanations".

Often, when I just start PS console and just launch

.\gadget-calendar



current day isn't highlighted.

I thought to have found a fix (if you read full thread I mentionned)
but it isn't.

I've seen that executing the same command several times gives the same
behavior (bug ?).

So, doing something like :

(1..100)|%{.\gadget-calendar;sleep -m 500}

As it's a sporadic behavior the range could be larger to see the
behavior (see image file joined to this message).

Problem seems to be with the following condition not always correctly
treated :

if($_.Trim() -eq (get-date $strdate).Day)

But why (and/or what do I wrong) ... that's the question(s) :-)

As hollidays are coming I'm not sure to have time to follow this thread
"in real time" (but I'll try).
So, if someone found something to submit on Connect (s)he's free to do.

TIA

Regards,

--
Jean - JMST
Belgium

You problem was one IF higher, as your get-date is not on the second the
same so you need some rounding, as sometimes the second is not equal:

if($strdate -ne (get-date))

Mo Tu We Th Fr Sa Su
True 7/1/2006 12:08:35 PM 7/1/2006 12:08:36 PM

################


You could change the default date in the params :

[string]$strdate=(get-date).date,

and change the check like this :

if($strdate -ne (get-date).date)
## Outputs calendar month grid ##

Greetings /\/\o\/\/

Jean wrote:
> Here is a strange behavior I've tried to isolate in a short reproduction
> code but unsuccessfully.
>
> So, sorry if I refer to a "long" code here:
>
> http://groups.google.com/group/micro...e=source&hl=fr
>
>
> See inside comments for "explanations".
>
> Often, when I just start PS console and just launch
>
> .\gadget-calendar
>
> current day isn't highlighted.
>
> I thought to have found a fix (if you read full thread I mentionned) but
> it isn't.
>
> I've seen that executing the same command several times gives the same
> behavior (bug ?).
>
> So, doing something like :
>
> (1..100)|%{.\gadget-calendar;sleep -m 500}
>
> As it's a sporadic behavior the range could be larger to see the
> behavior (see image file joined to this message).
>
> Problem seems to be with the following condition not always correctly
> treated :
>
> if($_.Trim() -eq (get-date $strdate).Day)
>
> But why (and/or what do I wrong) ... that's the question(s) :-)
>
> As hollidays are coming I'm not sure to have time to follow this thread
> "in real time" (but I'll try).
> So, if someone found something to submit on Connect (s)he's free to do.
>
> TIA
>
> Regards,
>
>
> ------------------------------------------------------------------------
>

> You problem was one IF higher, as your get-date is not on the second the same
> so you need some rounding, as sometimes the second is not equal

So, I'm stupid :-)
Great thanks wow.

Regards,

--
Jean - JMST
Belgium

Jean wrote:
>> You problem was one IF higher, as your get-date is not on the second
>> the same so you need some rounding, as sometimes the second is not equal
>
> So, I'm stupid :-)
> Great thanks wow.
>
> Regards,
>

No thank you,

I really like the script,it's in my profile already.
Great work

Greetings /\/\o\/\/

I've included it in my profile as well.
Very cool stuff.

--
Jeffrey Snover [MSFT]
Windows PowerShell Architect
Microsoft Corporation
This posting is provided "AS IS" with no warranties, no confers rights.
Visit the Windows PowerShell Team blog at:
http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:
http://www.microsoft.com/technet/scr.../hubs/msh.mspx

> So, sorry if I refer to a "long" code here:
>
>
> http://groups.google.com/group/micro...e=source&hl=fr

An improved version of the script is now available here :

http://groups.google.com/group/micro...e318dc9a?hl=fr

° parameter $strdate is renamed $vardate

° parameter $fullyear is removed.
To get a full year calendar just pass year as integer :
.\gadget-calendar 27
returns full year 27
.\gadget-calendar 2011
returns full year 2011

° a problem with 1st century years (1..99) fixed

Note :
Jacques Barathon reports me a bad rendering with a *post* RC1 version :
blank lines added between day's numbers rows.
This is not yet fixed .

Regards,

--
Jean - JMST
Belgium

one of the changes coming in RC2 is a change in single vs double quote
handling single quotes now really don't interpret characters, so `n is `n
not <CR>.

In line 102 you have

$table[$table.Length-1]+= '`n'
change this to double quotes:
$table[$table.Length-1]+="`n"

and it works as expected

--
--
James Truher [MSFT]
Windows PowerShell Development
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.

"Jean" <repondre@groupe.svp> wrote in message
news:mn.5b537d695bd3d86d.56820@windows...
>> So, sorry if I refer to a "long" code here:
>>
>>
>> http://groups.google.com/group/micro...e=source&hl=fr
>
> An improved version of the script is now available here :
>
> http://groups.google.com/group/micro...e318dc9a?hl=fr
>
> ° parameter $strdate is renamed $vardate
>
> ° parameter $fullyear is removed.
> To get a full year calendar just pass year as integer :
> .\gadget-calendar 27
> returns full year 27
> .\gadget-calendar 2011
> returns full year 2011
>
> ° a problem with 1st century years (1..99) fixed
>
> Note :
> Jacques Barathon reports me a bad rendering with a *post* RC1 version :
> blank lines added between day's numbers rows.
> This is not yet fixed .
>
> Regards,
>
> --
> Jean - JMST
> Belgium
>
>

> one of the changes coming in RC2 is a change in single vs double quote
> handling single quotes now really don't interpret characters, so `n is `n
> not <CR>.
>

This change is good to know :-)

> In line 102 you have
>
> $table[$table.Length-1]+= '`n'
> change this to double quotes:
> $table[$table.Length-1]+="`n"
>

As the single quote's "don't interpret escape char and variables"
behavior isn't needed in this script I've replaced all single quotes
with double quotes.
Also I note as a "best practice" to use single quote only if really
necessary :-)

> and it works as expected

Great thanks James.

Updated script is soon/now available here :
http://groups.google.com/groups?selm....56820@windows

Regards,

--
Jean - JMST
Belgium

> Also I note as a "best practice" to use single quote only if really necessary
> :-)

This could seem a detail but ...
I'm not sure to do a good choice here.

As using single quote, variables and escape parser aren't used (so I
suppose) can we consider the use of single quote faster than double
quote ?

If yes I prefer to give "priority" to single quote.
In this case, they are two lines in script using :

..Split('`n')

Do they need double quotes too (I think "yes" but ...) with RC2 ?

..Split("`n")

Regards,

--
Jean - JMST
Belgium

> Do they need double quotes too (I think "yes" but ...) with RC2 ?

Since RC2 is now out I'll can see that myself :-)

Regards,

--
Jean - JMST
Belgium