Jon Rista wrote: your client to upgrade to MS SQL Server
We are using MS SQL server and I am making use of views and stored procedures. First off views are a touch limited and I am no pro at stored procedures (where is the intellisense! .)
For instance part of pulling the product out of the database involves checking the users delivery country, checking various special offers and special rules and then calculating the price. It gets complicated because each order can contain multiple delivery addresses (e.g. you buy three items, two for yourself and one for a friend) and each item is priced according to weight, type and time of year. There is also gift wrapping, gift tags and multiple VAT rules (including the fact that some products are exempt from VAT in certain countries due to their type.)
So basically there is a lot of "business logic" going on which is all calculated from the base data.
Now I thought that was the whole point of classes and a data abstraction layer. i.e. The database persists data. Store procedures and views provide the data (and to some extent stored procedures do business logic) to the classes and then the classes do various calculations and offer up that data in a nice usable way for the programmer to implement into a nice UI.
You mention DataSets (and so did Paul) but how is that going to improve things? Surely I am still going to have to encapsulate all the business logic somewhere and still then provide the DataSet data up for use to the front-end (or do DataSets allow for "complex" calculations to take place "inside" them in some way?)
DataSets are really just an in-memory cache of your database, or a part of it. And they don't nessesarily have to have a GUI. They can be created in conjunction with a schema, allowing for all the relationships and whatnot to be properly maintained in memory. You could load your data from the database into a dataset, use that as your database while doing your calculations, etc, and then persist that back to the database server when your done. It can improve performance and help keep things properly restricted.
create a workthread in c# ,and use Thread.Sleep(100000) in it.and when the main app exited ,the thread is still working!!!!
call the thread.Abort() and thread.join(0).It seemed useless.
what is the problem???
Is that a framework's bug???
Paul Riley wrote: it finishes whatever it's doing first.
Correct, more specifically it will run until it gets to a safe place to throw the exception. In this case it waits until it is done running unmanaged code before throwing the exception (Thread.Sleep is actually a P/Invoke'd call to the OS, judging by ildasm output).
not exactly,thread.Abort() never worked.
you can try this:
Console.WriteLine("thread will sleep");
Console.WriteLine("thread is awake");
and after you called thread.Abort() and exit the application,the thread never stop.
Is that to say,abort() will never find a safe place to throw a exception????
Thread.Abort() does work...its just fickle. Its also pretty much required that you catch the ThreadAbortException that Thread.Abort() throws. Its also a good idea to call Thread.Join() immediately after your call to Thread.Abort(). Thread.Join() will cause the calling thread to wait indefinitely until the child thread terminates. If you do not put Thread.Join() in, the application can exit before the child thread does, in which case the child thread will most likely never exit. The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with. When the application exits, the ThreadAbortException can no longer be thrown, resulting in a dead thread that won't go away. I tried this, and it seemed to work fine (I tried 5 times, properly exited every time):
staticvoid Main(string args)
Console.WriteLine("[M] Starting worker thread.");
Thread t = new Thread(new ThreadStart(WorkerThread));
Console.WriteLine("[M] Killing WorkerThread...");
Console.WriteLine("[M] Main thread waiting...");
Console.WriteLine("[W] WorkerThread saying hello.");
Console.WriteLine("[W] WorkerThread saying bye-bye.");
Jon Rista wrote: The reason for this is the application repeatedly fires off the ThreadAbortException until its actully caught and dealt with.
On the contrary, you cannot fully catch the ThreadAbortException. Once execution has exited the catch block, the CLR will continue to rethrow the exception until: 1) Thread.ResetAbort is called which cancels the request to destroy the thread or 2) All of the finally blocks have exited, allowing the thread to die.
i have a problem with modeless forms...
When i click a button and execute the code below it works...
FormX MyForm=new FormX();
MyForm.Show(); // it creates a modeless form as expected!..
but when i call these two lines of code in another function such as a CallBack function like OnReceiveAsync() in my Client program or in a timer delegate function like Timer_Elapsed() it doesn't works...
it tries to create MyForm but it does not properly appears and it locks the whole program..
is it a bug? or should i do something else for Modeless forms & dialogs..
Please try it your self and see what happens..
Modal forms (MyForm.ShowDialog();)
works properly everywhere whether called by clicking on buttons or
calling via another function
but why modeless are not?..
can anyone help me out with the coding conventions that are recommended for .NET users.....as i would be recommended by micorsoft!
and a little bit of detail would be appreciated specially about naming controls...for example a textbox!
i have read all that...its inconclusive...
as i said i want concrete information what is the best way to name a control....there is no such description of controls on the msdn article....can you help me out with something else?
well when i mean control imean the controls as textbox and label how do you name these kind of controls in .net....do we use the hungarian notation or the new camel or pascal notations?
so what do you think?
At the moment I'm still using Hungarian for controls, while following the naming guidelines for everything else. Most code I've seen that tries to follow the guidelines adopts a similar approach. Some also still use Hungarian for fields, e.g, using a leading _ or m_.
To be consistent I guess we should really just use the full name of the control in camel case, e.g., customerTextBox, customerLabel rather than txtCustomer, lblCustomer, etc.
I've asked thsi question myself before and never got an answer. I don't know offhand where to find the Hungarian list (for controls). But, if you look under Visual Basic coding conventions for VB6 in the VS help or at the MSDN Library site you should find there is a list of this sort.
Pull up Help
Goto Index (or is it Search) and enter 'Naming Conventions'
This should point you to the Naming Conventions page which contains Hungarian Notation for all variables, forms, controls, etc.
In our group, we have chosen to move completely to the naming conventions specified in the CLS. So everything, private or public, follows the CLS nameing standards. Methods, classes and namespaces are Proper Case. Parameters, properties, variables are camelCased. I believe that the only exceptions we have made so far are with the rare fat client code and the form itself is still named frmFormName.
--------------------------------------------- Once I thought I was wrong but I was happy to discover that was a mistake.
Last Visit: 31-Dec-99 19:00 Last Update: 5-Dec-23 22:09