Navigation


Milos Solution Platform (External Blog)

The Milos Solution Platform is .NET's premier platform for building business applications. This blog is meant for developers who use or evaluate Milos. This blog is used to share tidbits of information provided by the Milos developers at EPS. Many of the posts put the spotlight on new features. We generally recommend that all Milos users (developers) at least scan this blog to keep up with the Milos news.

Content Area Footer

Monday, February 19, 2007
New WinForms Controls in Milos

The latest version of Milos has an entire set of new WinForms controls, subclassed from standard WinForms controls. These controls were of course available before as standard .NET controls, but not through the Milos abstraction layer, which also meant that they didn't have any Milos enhancements, such as Milos data binding. Some of these controls are new in .NET 2.0, others were sealed before and could thus not be subclassed.

The following is a list of controls that have been added to the SimpleControls namespace/assembly:

  1. EPSFlowLayoutPanel
  2. EPSHelpProvider
  3. EPSMaskedTextbox (supports databinding)
  4. EPSMenuStrip
  5. EPSProgressBar
  6. EPSPropertyGrid
  7. EPSSplitContainer
  8. EPSStatusStrip (use this instead of the EPSStatusBar control where possible)
  9. EPSTableLayoutPanel
  10. EPSToolStrip
  11. EPSToolStripContainer
  12. EPSToolTip

Enjoy!

 



Posted @ 4:58 PM by Egger, Markus (markus@code-magazine.com) -
Comments (5)


Monday, February 19, 2007
Atomic Save and Entity Verification

Milos supports a so-called "atomic save" across multiple Business Entities. This means that multiple entities (such as 3 customers and 10 invoices) can be saved with a single line of code and within a single transaction, assuming they all store their data in the same database on the same server using the same access method (such as LAN vs. Internet). This is a simple and elegant shortcut that saves a lot of coding

Note: If you need to save to different databases, you must use distributed transactions rather than an atomic save.

The following code performs such an atomic save on 3 entities (assuming these entities existed in memory):

BusinessEntity[] entities = { ent1, ent2, ent3 };
BusinessEntity.AtomicSave(entities);

This method returns true or false depending on success. False also means that the save failed and the entire atomic transaction was rolled back. Typically, one would check the broken rules within each entity to see what went wrong.

Note that in this operation, for performance reasons, all the entities are verified before any database operations take place. This is a huge performance and scalability gain, and thus very important.

Note that there is a potential catch here: If the verify of one entity relies on a previous entity having been saved, then the verify may fail although if the save would have taken place, everything would have been fine. For instance, if the atomic save saves an entity representing a product and a second entity representing an invoice using that product, then the result is undesired. (Of course one could argue that there is a design problem here, but that is not the point...).

There now is a new overload of AtomicSave() that allows to avoid the verify-first problem. Of course, this reduced performance since there is a potential for hundreds of entities being saved that all have to be rolled back (and of course one has to communicate with the server for that in the first place). So you want to avoid this as much as possible. But if you really need this functionality, you will be glad it is there. Here's how to avoid preliminary verification:

BusinessEntity.AtomicSave(entities, false);

 



Posted @ 4:11 PM by Egger, Markus (markus@code-magazine.com) -
Comments (11)


Monday, February 19, 2007
Milos Asserts

Here is a little known, yet very handy feature Milos provides: An enhanced Assert dialog, which looks like so:

As you can see, it is somewhat similar to the Milos exception dialog, but it really is pretty different, since the dialog mainly focuses on assert logic. So at the top of the window, we have the assert message. We also have a button to Ignore the assert (which closes the window) and another button to Ignore All asserts (of the same type). In addition, there is a Debug button which launches the debugger. This button is only displayed when the application runs in debug mode.

Then, there is a textbox that displays help information. This is something normal asserts do not do. This textbox is designed to provide additional help about how to fix the problem. This information may not always be available.

Then, there is error information that may be relevant for the assertion. Asserts are not designed to handle errors, but errors may be associated with asserts. These errors can be displayed here in the same fashion as the show up in the exception dialog. Note: This does NOT mean that you should use asserts to handle errors!!! Asserts do not execute in release builds, so this error handling would never shop up in a final build. Therefore, asserts can only be used to handle problems that can only occur during development and are likely to be developer errors.

For the obvious reason, this dialog only works in WinForms and WPF applications. Web applications, service apps, and pretty much all other types of applications behave different. Depending on whether or not a debugger is attached, either the standard .NET assert functionality is used to display the assert, or (if no debugger is attached), the information is sent to the console. This is handy, since it still provides very clear debug information when the developer debugs, but it does not freeze the server when a deployed debug build is running on a server (perhaps in a staging environment... you are not deploying debug builds, right? ;-) ). SmartClient apps that aren't EXE or XBAP-based WPF or WinForms apps behave similar to web and service apps when it comes to asserts.

Note that if the application (regardless of its type) is deployed in release mode, no asserts will be shown (Milos or otherwise).

Milos uses this feature for all its own asserts, but of course, you can (and probably should) also use the Milos Asserts in your applications. You can invoke them easily through the following syntax:

EPS.QA.Asserts.Alert(...)

Here is a little known fact: While all Milos asserts are suppressed in runtime build, you can still leverage the same dialog for other things using this method:

EPS.QA.Asserts.AlertWindows(...)

This is handy when you need it, since it is kind of a cool dialog. Just make sure you only use this in Windows apps, and also, do not abuse this feature to use asserts in stead of error handlers. After all, one wouldn't want to pollute overall design and implementation... ;-)



Posted @ 3:38 PM by Egger, Markus (markus@code-magazine.com) -
Comments (5)


 

 

 

 

 

 

 

Syndication RSS 2.0 RSS 2.0

All My Blogs:
My personal blogs:
Dev and Publishing Dev and Publishing
Travel and Internat. Living Travel and Internat. Living
Other blogs I contribute to:
Milos Blog (US) Milos Blog (US)
VFPConv. Dev Blog (US) VFPConv. Dev Blog (US)
VFPConv. Dev Blog (DE) VFPConv. Dev Blog (DE)

 

Blog Archives
All Blog Posts

2010
    November (1)
2009
    July (2)
    February (2)
    January (1)
2008
    December (1)
    October (3)
    June (1)
    April (3)
    February (1)
    January (1)
2007
    December (1)
    October (2)
    September (2)
    July (1)
    June (2)
    May (4)
    April (6)
    March (8)
    February (3)
    January (2)
2006
    December (2)
    November (2)

 

 

 

This Blog is powered by MilosTM Collaboration Components.