Hi all -



This is my first foray into Dynamic Business Object Events, so this may be a basic question...Reading the postings here and the SF Help they look very useful, so I want to understand them fully.



I created a Property Changing Event for one of my BOs (single event for all) and expected to see the FieldPropertyChanging event in my BO. Instead, I find FieldPropertyChanging only on the instance of the BO dropped onto a form. Not good, since I wanted to introduce behavior at the BO level that would be available to any form using it.



What am I missing?



TIA!

________________
_____/ Regards,
____/ al

Nothing.  This is how it is designed as they are dynamically created in the partial class.  However, to do what you are wanting, just create another BO that inherits the BO with the custom events if that is an option.

Could he also just manually manage the events? Just like the SetDefaultValues/CheckCurentRow(or whatever it is called...I always forget)? Then he wouldn't have to inherit.

These events are not intrinsic to a BO.  They are created through the BO mapper versus being defined on the BusinessLayer class.  So in this case, if you are wanting to add logic into a BaseBO then you will not be able to.  For example, the Navigated event is defined on the BusinessLayer class.  However, the dynamic events are strong-typed events and must be created at the time of the partial class creation.  Thus making it more difficult to add logic to a base BO in this scenario.

Thanks to both of you for your replies... helps the learning process.



So basically for situations like this (which in the application I'm building will be needed for most of the mainline BOs) the process would be something like this.



1.) Create a business object and map to a datasource via BOM. Set the advanced properties in the BOM to generate any dynamic business object events I want. Let's call this one boFirst.



2.) Create a second business object in the usual fashion (but don't BOM it). Instead, change its base class to boFirst. This will provide this second business object (let's call it boSecond) with all of the strongly types columns created via the BOM process performed on boFirst, plus the dynamic events found in the partial class for boFirst.



Seems reasonable and a good solution.





Assuming the above is correct, two follow-up questions.



1.) After doing the above, I see the strongly typed columns and the generated dynamic events in boSecond. When I go into the BOM I see boSecond, but it has a red X on it as it is looking to be configured to a data source. I am assuming I just let it sit like that and do not actually configure it? That being the case I assume over time I'll have some "first line" BOs that are fully configured in the BO, and a bunch of "second line" BOs that have red Xs in them. Hmmmm... ?



2.) Are any time-saving techniques I can use to replace boFirst with boSecond on any forms I've already created and for which many controls are bound. Obviously I can do the brute force approach and rebind, or I can rename the instance of boSecond I'll drop on the forms to boFirst (but that might irk me a bit as it may be misleading). No biggie if there's not a way... it's still all good, although it makes me wonder if there's value in always doing the above two steps just in case there's a similar need in the future.



Thanks!

________________
_____/ Regards,
____/ al

Ya learn something every day. Didn't know that about events.



On the red X in BOM, you are correct about just ignoring them. There has been at least one enhancement request to somehow be able mark BO that aren't ever going to be mapped (like you will have and also base BOs). I'm hoping this request happens soon.



As to how to update your forms that are using the "first line BO" and now need to use the "second line BO", I think the easiest would be to directly update the designer file of the forms. Do a search and replace on the "first line BO" type, replacing with the "second line BO" type. I.e. the BO will have the same name, the bindings will still be valid, event handlers will still be valid, etc. you are just changing the type of that BO. I do this frequently in just this sort of situation: were I've subclassed some control or BO and now need to use the new one.

Yeah, I can really see that being desirable. I am not a big fan of having to be able to distinguish "good" red Xs from "bad" red Xs. Don't want to offend anybody, but they all look alike to me! I'd definitely vote YES to that request!





Funny... I was thinking along the same lines. I am relatively new to .NET and have been told the designer files are off limits; you just don't touch them unless you want to trigger a plague somewhere. That said, I come from a Visual FoxPro background and it's just not uncommon to do lots of hacking "behind the scenes" to get things done quicker and more effectively.

_____________________________________________________

Appreciate the insight and suggestions, Greg!

________________
_____/ Regards,
____/ al

Hi Alex,

Don't worry, just make a backup of the 3 files in case something goes wrong. I do this all the time and the Find/Replace feature in the VS IDE is much more powerful than the one in VFP IDE. I just used it to replace all references in 2 forms (parent/child) which the whole table design changed completely and I did not want to re-do all the logic in both forms, I am using a listview with several fields in both forms and at the end the form worked just fine. I suggest you do this one step at a time so you don't loose track of what is being replaced, and don't use "Replace All"

Edhy Rijo

As an alternate to doing a copy, just make sure you've committed the form to source control before making the changes. They you just need to do a revert in case of a problem.



A really important thing to understand about designer files is that they aren't magic. They do nothing you couldn't do yourself. In fact, there's nothing you can do in VS that you can't do in Notepad. However, if you used notepad, it wouldn't be much fun (no designers, no declarative programming using property sheets, no visual form building...).



Of course you can break things such that VS can't open them in a designer, but since VS often breaks things so they can't be opened in a designer, you'll likely need to start getting comfortable opening the designer files anyway!



I also second not using Replace All. Every time I've done that, I ended up breaking something, either because there was some match that wasn't appropriate or because I intended to replace all in the current file, but had entire solution selected.

Sounds great... but I think I will wait until Monday to start hacking the designer files for my project... it's been a loooonnnggg week and synapse is not firing as it should right now!



Have a good weekend guys, and thanks again.

________________
_____/ Regards,
____/ al