Yes, when registered in a string format these values work just fine.
It seems to definitely be a casting issue.
On Oct 13, 4:13 pm, "Shawn Hinsey" <[EMAIL PROTECTED]> wrote:
> Have you tried replacing the component reference with a string in
> Timespan format, just to make sure nothing else is awry?
> Alternatively, try configuring the referenced TimeSpan object with a
> string via the parameters and lose the factory stuff. If that works,
> at least you've isolated the issue, and someone more familiar with the
> factory facility can probably chime in with the fix.
>
> On Mon, Oct 13, 2008 at 5:11 PM, George Mauer <[EMAIL PROTECTED]> wrote:
>
> > I can't be 100% sure since I'm still very new at all this but I would
> > imagine not since I can do
> > IoC.Container.Resolve("time_alert_dialogs_remain_on_screen") with no
> > problem
>
> > On Oct 13, 4:02 pm, "Shawn Hinsey" <[EMAIL PROTECTED]> wrote:
> >> I'm not very familiar with the factory facility is why I ask. Is it
> >> possible that the object isn't in a valid state at dependency
> >> resolution time?
>
> >> On Mon, Oct 13, 2008 at 5:01 PM, Shawn Hinsey <[EMAIL PROTECTED]> wrote:
> >> > How are you setting the value of time_alert_dialogs_remain_on_screen?
>
> >> > On Mon, Oct 13, 2008 at 4:59 PM, George Mauer <[EMAIL PROTECTED]> wrote:
>
> >> >> I want the value to come from a property on a Settings class that gets
> >> >> passed around to a related group of objects. I would prefer the
> >> >> Settings class to be strongly typed. It would seem to me like that's
> >> >> a pretty common way of doing things, if I'm going about it the wrong
> >> >> way by all means tell me, since I'm just pulling this stuff out of my
> >> >> butt.
>
> >> >> On a side note, I'm also running into this issue when the constructor
> >> >> takes an Int32 and, I assume I will run into it with any non-reference
> >> >> object.
>
> >> >> Without digging into the code, it seems like the input of a parameter
> >> >> is assumed to be either a reference type or a string and no attempt at
> >> >> casting is done. I would be surprised if someone hasn't run into this
> >> >> annoyance before and written a module to solve it so if any can point
> >> >> me in the right direction it would be greatly appreciated.
>
> >> >> On Oct 13, 3:51 pm, "Shawn Hinsey" <[EMAIL PROTECTED]> wrote:
> >> >>> I've had luck with creating timestamps using the format "HH:MM:SS" in
> >> >>> the component parameter configuration, but I've never tried that
> >> >>> approach. Do you need to have a separate component for the timespan?
> >> >>> You could put the value in a property if it's reused.
>
> >> >>> On Mon, Oct 13, 2008 at 4:07 PM, George Mauer <[EMAIL PROTECTED]>
> >> >>> wrote:
>
> >> >>> > I have a variety of classes in my project that take a TimeSpan in the
> >> >>> > constructor which is to be provided from a settings class. So as an
> >> >>> > example, I have things wired as follows
>
> >> >>> > <component id="timed_alert_dialog"
> >> >>> >
> >> >>> > service="DriverInterface2.UI.Presentation.UIInterfaces.ITimedDialog,
> >> >>> > DriverInterface2.UI.Presentation"
> >> >>> >
> >> >>> > type="DriverInterface2.UI.WinForms.Dialogs.AlertDialog,
> >> >>> > DriverInterface2.UI.WinForms">
> >> >>> > <parameters><timespan>${time_alert_dialogs_remain_on_screen}</
> >> >>> > timespan></parameters>
> >> >>> > </component>
>
> >> >>> > <component id="time_alert_dialogs_remain_on_screen"
> >> >>> > type="System.TimeSpan"
> >> >>> > factoryId="global_settings"
> >> >>> > factoryCreate="get_TimeAlertDialogsRemainOnScreen" />
>
> >> >>> > But when I try to resolve timed_alert_dialog I get the following
> >> >>> > error:
> >> >>> > {"Could not convert from '${time_alert_dialogs_remain_on_screen}' to
> >> >>> > System.TimeSpan"}
> >> >>> > Inner Exception: {"Input string was not in a correct format."}
>
> >> >>> > Some things I have learned while experimenting:
> >> >>> > I can resolve time_alert_dialogs_remain_on_screen (the TimeSpan)
> >> >>> > properly with no problem.
> >> >>> > If I change the constructor to take an object that is later cast to a
> >> >>> > TimeSpan then it works fine also.
>
> >> >>> > This last point indicates an annoying yet quick way to resolve the
> >> >>> > situation which is for obvious reasons, less than ideal. What is the
> >> >>> > cause of the problem and is there any way I can resolve it for real?
>
> >> >>> > Thanks a lot,
> >> >>> > George Mauer
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---
