ioc Issue Tracker Rss Feed

Closed Issue: Feature Request: Add non-XML-based (preferrably fluent) Dynamic Registration interface [2758]

ctacke — Mon, 25 Mar 2013 14:45:10 GMT

We need to add some mechanism to make programmatic registration of modules easier. One that doesn't require XML, and preferrably fluent (since that seems to be the way everyone else is migrating).
Comments: Change set 71475 added GetModuleAssemblies to the IModuleInfoStore interface. You can now return an array of assemblies here and they will get inspected for modules and loaded. It's not fluent, but it's an alternative to XML.

Closed Feature: Feature Request: IModule loading without UI [6870]

ctacke — Mon, 25 Mar 2013 14:43:16 GMT

Right now the ModuleInfoStoreService (the thing that loads IModules - which are essentially plug-ins) is tied to the SmartClientApplication, which in turn required WinForms. IModules shouldn't be tied to UI requirements first, becasue it's bad form, but also becasue it makes it so you can't reasonably use the IModule loading feature on platforms like Mono where WinForms don't exist.

Extract the IModule loading system out of the UI assembly and down into IoC. Make it no UI dependent. Keep it performant, or better yet, make it faster. Maintain existing compatibility.
Comments: This is fixed, though I don't recall exactly when I fixed it. The latest change set (71475) definitely has it.

Closed Issue: Feature: Allow loading module assemblies without XML [7372]

ctacke — Mon, 25 Mar 2013 14:41:47 GMT

In some cases I'd like to be able to load assemblies with my own logic, rather than from XML. Being able to just load the Assemblies myself and passing them into the IoC framework for Module inspection would be useful.
Comments: Implemented in change set 71475

Closed Feature: Feature: Access to the Shell Form in SmartClientApplication [7371]

ctacke — Mon, 25 Mar 2013 14:41:23 GMT

If I create a typical IoC.UI SmartClientApplication, the shell form is created for me based on a generic type reference. That's great. But it's causing me a problem with app shutdown.

Right now I have an app that hides the OS taskbar (CE) on startup. On shutdown, I'd like it to show it again. My Form shell form hides the Task Bar in the constructor and there's code to re-show it in the Dispose method, but Dispose is never getting called - I think the runtime exits before that can happen.

What I need is access to the shell form's instance up in the SmartClientApplication so I can call in and re-show the task bar after Start method exits.
Comments: Implemented in change set 71475

Created Issue: Feature: Allow loading module assemblies without XML [7372]

ctacke — Mon, 25 Mar 2013 14:38:02 GMT

Commented Feature: Feature: Access to the Shell Form in SmartClientApplication [7371]

ctacke — Mon, 25 Mar 2013 14:30:38 GMT

Oh, and maybe explicitly Disposing the shell for before exiting would be a good thing as well.

Created Feature: Feature: Access to the Shell Form in SmartClientApplication [7371]

ctacke — Mon, 25 Mar 2013 14:29:59 GMT

Created Feature: Feature Request: Load Modules by Assembly [7326]

ctacke — Wed, 20 Feb 2013 02:17:45 GMT

Currently the IModuleInfoStore uses XML to define what Modules get loaded. This isn't terribly friendly, especially for platforms like Android. It would be nice if I could just pass back an array of Assemblies that my InfoStore loaded and have IoC scan that for IModules to load.

Created Feature: Feature Request: Add usage analytics/metrics [7267]

ctacke — Wed, 16 Jan 2013 14:31:11 GMT

If your app is using IoC, then a lot of calls get funneled through some very discrete points in the code. It might be useful and interesting to add at least some basic counters to help developers profile application usage. For example, keeping a running count of SmartPart activations could tell a developer the relative "popularity" of a given View. keeping a count of service resolutions by type could likewise indicate which services are most used. This wouldn't take the place of full app instrumentation, but it could provide some simple, easy data to help developers decide where efforts are best spent.

Closed Issue: Automatic textbox focus on loading [7137]

ctacke — Tue, 15 Jan 2013 15:10:19 GMT

I would like for my SmartPart to have it's first textbox focused on when it loads. I have the below code in the OnActivated() method of my SmartPart:

public override void OnActivated()
{
base.OnActivated();
txtUserName.Focus();
}

However, after the workspace.Show method is called by the DeckWorkspace, the textbox is not focused.

I can make a sub-classes of the DeckWorkspace and SmartPart with auto-focus methods added, but is there a way that doesn't use new classes?
Comments: Fixed with latest change set

Commented Issue: Automatic textbox focus on loading [7137]

ctacke — Tue, 15 Jan 2013 15:09:55 GMT

It turns out that the CF has a different behavior than the desktop. A Form's Visibility doesn't change until after the ctor has run. Well a control's visibility cannot be set to true if it's containers are not visible, and things like SetFocus are ignored if a control is not visible. The end result is that on the first creation of the Form, SetFocus was failing - for every time after that (when just showing and hiding) it was working fine.

The net result is that I've fixed the issue, though if you try to start a Form hidden, it now might interrupt that process. We'll see if anyone flags that as a problem.

Commented Issue: Automatic textbox focus on loading [7137]

pbond — Mon, 14 Jan 2013 21:22:20 GMT

I would like for my SmartPart to have it's first textbox focused on when it loads. I have the below code in the OnActivated() method of my SmartPart:
 
public override void OnActivated()
{
 base.OnActivated();
 txtUserName.Focus();
}
 
However, after the workspace.Show method is called by the DeckWorkspace, the textbox is not focused.
 
I can make a sub-classes of the DeckWorkspace and SmartPart with auto-focus methods added, but is there a way that doesn't use new classes?
Comments: ** Comment from web user: pbond **

I can reproduce issue on WorkspaceDisposal sample (Compact Framework on Pocket PC 2003 emulator)

Issue also reproducible on real Windows CE devices

```
//Constructor
deckWorkspace1.Add(view); //
view.Show(); // OnActivated event occurs , but textbox control is not focused

// Button event handler
view.Hide(); //
view.Show(); // text box control is focused

```

Commented Issue: Automatic textbox focus on loading [7137]

pbond — Mon, 14 Jan 2013 11:55:30 GMT

I can reproduce issue on OpennetCF.IOC.CF

Commented Issue: Keydown Events inside SmartParts [7129]

webber55 — Mon, 01 Oct 2012 13:53:38 GMT

I need for my Smart Part control to react to KeyDown events for my application.

However, once a smart part is loaded into the workspace, I cannot get the keydown events to be captured.

I added the below code to the ViewA.cs and ViewB.cs Smarts in the FormStackCS sample project. The KeyDown event is captured and reacted to in ViewA at the start, but after changing what control is shown, the KeyDown event is no longer captured by any other form, even after returning to ViewA.

this.KeyDown += View_KeyDown;

private void ViewB_KeyDown(object sender, KeyEventArgs e)
{
var y = MessageBox.Show("A key was pushed");
}
Comments: ** Comment from web user: webber55 **

I'm sorry, but I downloaded the latest Source Code and the problem still happens in the FormStack sample project. Key events work for the first control loaded, but subsequent controls don't catch KeyDown or KeyUp events.

This still does occur in the FormStack sample program. I added the below events to the designer for the ViewB and ViewC SmartParts.

this.KeyDown += new System.Windows.Forms.KeyEventHandler(ViewB_KeyDown);
this.KeyDown +=new System.Windows.Forms.KeyEventHandler(ViewC_KeyDown);

private void ViewC_KeyDown(object sender, KeyEventArgs e)
{
var z = MessageBox.Show(string.Format("A key was pushed in View C {0}", e.KeyCode));
}

private void ViewB_KeyDown(object sender, KeyEventArgs e)
{
var x = MessageBox.Show(string.Format("A key was pushed in view B - {0}", e.KeyCode));
}

Closed Issue: Logging Switch On\Off [7066]

ctacke — Fri, 21 Sep 2012 18:04:32 GMT

It is good to add ability to turn off "Debug.WriteLine()". This were added in last versions, because there are some apps which uses own logging and this makes some mess in logging, so it would be good to turn off it by default and turn on if needed.
Comments:

Closed Issue: Feature: Gesture support in Workspaces or SmartParts [7087]

ctacke — Fri, 21 Sep 2012 18:03:42 GMT

Basic gesture support (left/right/up/down) might be a cool addition to the framework. It could aid in having CF apps be a bit less archaic.
Comments:

Added this feature in the latest code base

Commented Issue: Automatic textbox focus on loading [7137]

ctacke — Fri, 21 Sep 2012 18:03:06 GMT

I updated th desktop sample app WorkspaceDisposal.FFx.VS10 to test this and I was unable to reproduce it. In OnActivate I set focus to the first textbox in the SmartPart. I scrolled though all activation mechanisms, moving focus to a second textbox between each, and the focus always properly moved back to the first.

Could you provide more details on how to reproduce this error?

Commented Issue: Keydown Events inside SmartParts [7129]

ctacke — Fri, 21 Sep 2012 17:59:56 GMT

This was a result of the SmartPatrt not getting focus when it was activated. The latest change set fixes it.

Closed Issue: Keydown Events inside SmartParts [7129]

ctacke — Fri, 21 Sep 2012 17:59:08 GMT

Created Issue: Automatic textbox focus on loading [7137]

webber55 — Fri, 21 Sep 2012 14:02:43 GMT