Bah! Kids these days... don't know how good they have it. Back in my day.... :zzz:

Did you read the first line of the Reveal Focus Doc you have linked at the bottom?

Quote:

Reveal Focus is a lighting effect for 10-foot experiences, such as Xbox One and television screens.

Last I used an Xbox or TV screen it seemed quite a bit different than a pad/phone. ;)

That's a shame for those people. You give an organization PII and PHI with the assumption that they are going to protect it and then something like this happens. Medical info is the most valuable there is on the black market. 10x more valuable than working credit card numbers. :( Problem is that these places, especially in healthcare, are so out of their league when it comes to IT and IT security. And so many of them don't have a grasp on the risks that they face. I'm not sure what the protections are over there. In the US that company might was well close up the doors. HHS would could hit them with $10K fine per record.

Because it is a smart thing to do. ;) Both allow you to stub out or define aspects of a class that you may know but not completely or you may not be the one ultimately filling in the functionality. Interfaces allow you to specify what properties, methods, and events MUST be present on an object that conforms to that interface. Take, for example, INotityPropertyChanged. If an object implements that interface, then it MUST expose a PropertyChanged event with a specific signature. When another object wants to be notified that a property changed, it can inspect the target class to see if that interface is implemented and if so, hook the event. Because now you know what the event name and signature must be. Interfaces, however, only specify the properties, events, and methods that a class must expose and a class may implement more than one interface. Abstract classes, however, have a bit more meat on their bones. They are actual classes but simply stub the method functionality leaving it to be implemented in a class that inherits from the abstract class. A good example might be a data access object that exposes some data stored in the database. You would define an interface for the class including the methods needed to get and save data. You might then create an abstract class that provides some basics but doesn't include any details on how to get to the database. Finally, you might create two or three concrete classes from the abstract class that each know how to connect to a specific database server... maybe one for SQL, another for Oracle, and a 3rd for NoSQL. At runtime you can use reflection to find the proper concrete class and load it. Your code works with only the interfaces but at runtime is provided with the concrete instance of the appropriate class. HTH! Jason

Ugh! Why do some vendors insist on doing things their own way instead of the way everyone else in the world does it! Good luck. Polling is always a fine art of balancing responsiveness against overhead. Thanks for the good wishes. We are buried in snow here in the Midwest US and I am VERY ready for fireworks season to return!

I usually find this is an issue for two reasons: - A (dependency) property on a control is not being set in the default or specified style. This usually happens most on custom controls or controls where I have overridden the default template. Specifying a default value for a property in the default style will usually make this one go away. - A custom control (or extended control) doesn't handle the binding to a null object correctly. If, for example, you have something bound to a property on a view model but that property is a nullable type, in design mode it will probably be null. When the design surface mocks the VM to present a design-time view, the property evals to null and can throw an exception if the control doesn't handle it properly. If it is a control you wrote/overrode, you can fix it by handling a null value bound to the offending DP. Otherwise, add design-time code to provide a valid value for the offending VM property. (If you are using a framework like MVVMLight, IsInDesignMode is part of the VM base class. Otherwise, System.ComponentModel.DesignerProperties.GetIsInDesignMode will tell you. Beyond this, good luck. Xaml designer exceptions are especially painful to try to decode. It won't make you feel any better but I've even had the design surface crash repeatedly but clear up after a reboot.

I'm not sure the hit test is the problem. I didn't dive in really deep but when you move your mouse over the table, the cursor switches to the cross to indicate moving the table. However, you have to click to move the table. I'm guessing that clicking on the header of the table is actually activating the table move logic... meaning the "move" action is swallowing the click on the header you want. I suggest moving that table move functionality down. If you want to click on the header and show the size adorners then move the cross/table move functionality down in the visual tree. Or switch to a double-click to show the size adorners. (That would seem more "normal" to me anyway) HTH!

I'm curious why you need to constantly get feature information from a HID device since the feature set of a device should be static and fetching it once in response to a connection event I would think would be sufficient. However, it's not for me to judge... ;) If the function doesn't support async there is no way to make it act that way without implementing some sort of polling. Unlike making an async call synchronous, there is no 'await' for functions that don't use a callback and immediately return. That being said, it isn't too hard to implement your own. Setting up a background worker or some other threading solution (even a system.threading.timer can be used) so you check at a given interval is very common. It used to be used a lot with serial comms to check the input buffer. The only gotcha is to make sure you have an abort so your app doesn't hang at close. If you use a timer with a polling interval it will automatically abort when your app shuts down. Also, make sure you handle the cross-thread marshal if anything is going up to the UI.

Sorry for the delay getting back... I understand your concerns. You didn't say that you are using MVVM but since you are talking about a model class I'm guessing you are, in fact, using it. If that is the case, you should put all of your database code in the model. The idea of the model is to hide the details of the backing data store so you could switch it out if you needed. So it may feel dirty but that is exactly what you are supposed to be doing. I have fallen into a pattern where I usually create two classes for data. I'll call them DataObject and DataModel (really xxxxObject and xxxxModel as appropriate). DataObject represents the actual data and is typically nothing more than a class with a bunch of public properties. I usually inherit INotifyPropertyChanged and INotifyDataError on that class so that it can alert to value changes and it can alert to bad values. The second class, DataModel, is where I put the data access functions. This class is data source specific and usually implements an interface I have specified with the functions I'll need. In your case, this class might expose a function like:

public CategoryBase GetCategoryById(int Id)

which would obviously return a category based on an Id. In your ViewModel you would have a property which would take a category ID and in the setter you would call the GetCategoryById then use the results to set the category and Id on the property exposing that data object. As long as the underlying DataObject implements INPC and you have bound to a non-null category object at startup, then the category and Id should follow along with changes in the Id sourced from the combobox. The grid complicates things a bit because you have a collection of the data objects but that is pretty easy to work around. If you are uncomfortable wiring it up from the property setter for the Id property, remember that Combobox exposes a selection changed event. You could bind a command to that and use that as a jump point to call the DB fetch method and set the category data object. Ultimately though... I suggest you take MVVM as a suggestion and not a set of hard and fast rules. Like a lot of stuff in software development, there is always some scenario that doesn't fit the rules so we end up breaking them to make it work. If you figure out a system that works, then consider it a success. Just document the code so the next guy can see why you did what you did and why you broke the rule. :-\

Just out of curiosity... is the Category property not null when the initial binding occurs? Meaning you set the Category property the combobox is bound against to an instance of your class either at the declaration of the backing variable or in the datacontext constructor? There is an annoying "feature" that if you try to bind to a property that exposes an object and that object is null when the binding occurs, then eventing doesn't work. For example, if you bind a combobox itemsource to a collection that is initially null, even if you set the property to a fully-populated collection later, the combobox will not pickup the change. There has to be an instance of the class exposing the PropertyChanged event at the time of the binding for it to work. Especially helpful in these cases is that there are no errors. Raising the property changed event just goes nowhere.

Instead of

    public SCategory Category 
    {
        get { return category; }
        set
        {
            if (category == value)
                return;
            category = value;
            OnPropertyChanged("Category");
        }
    }

Make it this:

    public SCategory Category 
    {
        get { return category; }
        set
        {
            if (category == value)
                return;
            category.Id = value.Id;
            category.Category = value.Category;
            OnPropertyChanged("Category");
        }
    }

By doing that you will invoke PropertyChange on the Id and Category properties and items bound to those properties should get the event and refresh their values. Also, you have a bad naming convention by calling your derived class Category and a property of the base class Category. That won't do you any favors when you are trying to unwind the bindings and class relationships. You might want to rename the class... maybe CategoryClass or CategoryObject. HTH - Jason

Assuming that your category object has members like "Id", "Name", "Description", etc I'm guessing that you want to change the Id via the combobox and have the rest of the properties follow suit. There are a couple of ways of doing it but knowing that it all starts with the property setter for Id is the key. When the user selects an item in the combobox, it sets the SelectedItem property to the value or object you have specified. If it is a binding (as in your case) the setter gets called for that property. A normal setter, as you know, usually looks like:

set
{
if(_internalVar != value)
{
_internalVar = value;
RaisePropertyChange("PropertyName");
}
}

That works fine and raising property change there notifies any controls bound to that property that there is a change in it they should grab. But it doesn't do anything else. Even if you added a SelectedCategory property and bound that to the combobox then exposed name and ID through the internal variable, you still wouldn't fire the property change on the name property when the whole object was changed. That is because the binding system just isn't that smart. It must be told there is a change. So you have a few options... - If the combobox changes the ID, then in the setter for the ID property, change the name property as well. If you do it like Name = newValue then prop change gets raised in the setter for Name. If you use the internal variable like _name = newValue then you must follow that up by explicitly raising propertychanged passing Name as the property that has changed. - You could expose just an ID property and in the setter call a method that sets the values on the category object. Again, if you use the public property setters you will get the event raised. If you use the internal versions, you must raise the event. If you breakpoint on the Id property setter, property getter, and the same for the Name property, you will see how those things get called. (Basically setter followed by the getter in response to the event) To get the Name to update on the control, that PropertyChanged event needs to be raised carrying "Name" as the property name. How you get there is up to you. Unfortunately, debugging bindings isn't always the easiest thing... in fact it can be pretty infuriating. A lot of times I'll break on those property setter/getter and start working backwards to figure out why something isn't working. And don't discount typos either. I can't tell you how many times a stupid typo wh

Check the output window of the debugger for a binding error. Without the entire context of what you are doing I would guess the problem is the binding of the textblock. Inside the data template, the data context is the current row of the data set repeated for each item in the set. So if you had a data context for the page which had a collection of categories and a collection of objects which had a category and a name, your combobox source is correct and will bind to the collection of categories. However, the selected value will bind to .Category.Id where row is an object in the collection holding the rows withing the data context. Your bindings should be relative to that. If your row contains a "category" object, your bindings are correct and the problem is likely that you aren't raising PropertyChanged for the Name property when you are changing the Id property. If I could see the class that is your DataContext I could be more specific. HTH

Yes... that's true. But the post isn't about a hobby project. The OP is proposing a commercial product to go up against a number of established players. So while I appreciate the input, your comment really has no bearing on the discussion at hand.

There are some alternatives... LightWorks is a major player with pro editors. A few motion pictures have been done on it and it continues to pick up penetration each year. It isn't poised to knock off any of the ones you mentioned but then again Google didn't start out with 100% market share either. The regular version (which is fairly capable and will teach you the basics) is free while there is a pro version that will set you back a massive $60 USD/yr. LightWorks uses a different paradigm than the standard timeline-based editors and it definitely takes some getting used to. However, I think it is a good setup and once I learned it I think it has some advantages in the way the workflow is setup. I suggest giving it a look if you are tired of getting screwed by the big 3. As for my rant... As a developer, I think we sometimes walk around feeling like we are holding the hammer and every problem is a nail. In our limited exposure to any market, we think that there is a glaring gap that hasn't yet been filled or a major business opportunity that we can quickly write a script for and head for the sand. But any serious business venture starts out with lots and lots of research to understand the need, the opportunity, and to validate our ideas and assumptions before we even start a line of code. I'm not suggesting what you propose can't be done... quite the opposite. But I'm not sure that an enthusiastic posting on a coding site is the best start to a massive software project. (Unless you are looking for people to shoot you down... :) ) Many, many great software projects start with someone that sees a need and writes something that fills a void. I certainly think what you propose is possible and I hope you really can get something going, get some momentum, and release something useful and timely. But having been involved with some of this startup kind of stuff for a few years, I suggest making sure you know everything there is to know about the NLE segment... who the players are, what the advantages and disadvantages are of each, and get an idea of what your solution will do and what it will offer. I also suggest starting SMALL and getting something out the door quick and into people's hands. Yes... they may blast it as useless for their needs but they will provide useful feedback. Your best ideas will come from your users who approach the problem without preconceived notions about what your software should or shouldn't do. Maybe write something that will let you import clips, set trim points, an

LINQ is your friend when walking XML files. There are a lot of examples using Linq queries over XML to get data out of the file. I'm too lazy right now to Google it or search here on CP so I'll leave that to you. But that should get you what you want.

If you need info from the user that is required and is simple, then yes, I think it is OK to open it from the code behind. Remember, the separation of concerns in MVVM is to support testing of the VMs and the models independent of the view. So if you need to pop an input box or a file dialog or something from the control's code-behind, then go ahead if that is what makes the most sense. That being said... although I think it is OK to do if that is what it takes to solve the problem, I think you are taking out some technical debt if you do it this way. You may want to reconsider your whole approach a bit. Normally, you would want the view model to react to a change in state in the view. With a control in the view you would normally want it to react to a change in the properties on the VM it is bound to. So generally, you would enter a state whereby a new employee needs picked, the VM might open a window to get the selection from the user. Then you would validate that result (in the VM) and set the property on the VM that your control is bound to so it can display the information. Generally we try to keep the brains out of the controls because that complicates things and makes it harder to maintain. The control should basically be able to take some information and display it. Any logic more than that should generally be in the VM. And as one last thought... does your control need to know anything about the backend data other than being bound to a collection of the available options? Meaning, is there any logic in the control to manipulate the backing data such that there is a dependency on the backing data? Or, in other words, do you have strongly-typed references to data objects in your code behind? If so, that is definitely wrong. (References to members as part of the data template in code or in xaml don't count) HTH.

I got selected to learn programming in 4th grade on an Apple II+ by my elementary school teacher. (1982-83) Our district got enough machines to put a half dozen in each school but there was no formal curriculum at the time so it was all pretty unofficial and ad-hoc. When I got to high school in 87, our computer teacher was awarded one of IBM's first Teacher of the year awards for his program "reach out and byte someone" (1988) which taught students how to use dial-up resources like CompuServe to help with research projects. Big Blue donated an entire lab full of PS2's networked to a server all running Netware. It was amazing at the time and really put some fire to the districts' computer cirriculum. I started learning Pascal on that network in '89. Gave me a big leg-up when I got to college.

Connection strings are provider-specific. The sting you have there uses an Excel file as the "data store" but you are passing SQL-server parameters with InitialCatalog and IntegratedSecurity. Those aren't parameters the "Excel data provider" understands.

You are correct that there are better ways to do this. I was building off of your example... not following the cleanest way to do it. Plus, that is sort of a moving target. What you think may be the cleanest way to do it I may think isn't. So my goal was to show you one way of achieving what you wanted using the framework you had setup. The driving factor for my example is that you have a sub-view which you put into the content of the grid in the main view. You create a view model for both the host (main) view and the sub-view. The key thing here is to understand that despite declaring the sub-view as a 'user control' it isn't a control in the traditional sense of the word. That is why DP implementation is a bad choice in this situation. In fact, I hate the "user control" terminology because I think it muddies the waters. They should have called is a "user view" instead but since the class inherits from Control I can understand the naming. So your demo had a main view and a sub view both with view models attached to them. In order to communicate between those two view models in a way that doesn't create a dependency between them requires a third party. That could be command classes, a static or singleton class (as I demonstrated), and a messaging facility. The specifics aren't as important as choosing what is right for your situation and avoiding a dependency between the view models. Circling back around I think I'm understanding where you want to go with this and where we are missing the mark. I think you want the picker to be a CUSTOM CONTROL so you can put it on the main page and have access to the selected item as a property on that control. That is very different than the approach you took in the demo app. The architecture with the views and view models threw me. A custom control actually has nothing to do with MVVM or view models but rather is a marriage of a code file that inherits from control and a xaml template that skins the control typically defined in /Themes/generic.xaml. In this case you can add properties and methods to the class to create the behaviors you want that control to have. That is the time to use dependency properties... but they go on the control class. Custom controls aren't for the faint of heart. There are a number of required moving parts and some very specific requirements. I've got a three part article series that takes you from a blank project to a working custom control but it is still in draft status. I'll try to hurry up and get it published. It would be a good read