|
Thank you for comment. This is best what I can do. If you have better solution. Please share it.
|
|
|
|
|
|
Bayram Demirci wrote: This is best what I can do.
No, this is what you've done so far, and you can do better by studying the posts in this thread carefully.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
|
namespace CustomControls
{
public enum NumModel
{
PositiveInteger,
PositiveFloat
}
public class NumberTextBox : TextBox
{
private NumModel numModel = NumModel.PositiveInteger;
public NumModel NumModel
{
get
{
return numModel;
}
set
{
numModel = value;
}
}
protected override void OnKeyPress(KeyPressEventArgs e)
{
if ((e.KeyChar >= '0' && e.KeyChar <= '9') || (e.KeyChar == 8) || (e.KeyChar == 46))
{
if (numModel == NumModel.PositiveInteger)
{
if ((e.KeyChar == 46))
{
e.Handled = true;
}
else
{
e.Handled = false;
}
}
else
{
if ((this.Text.Contains(".") && (e.KeyChar == 46)))
{
e.Handled = true;
}
else
{
e.Handled = false;
}
}
}
else
{
e.Handled = true;
}
}
protected override void OnKeyUp(KeyEventArgs e)
{
double num;
if (this.Text != null && this.Text != "" && !double.TryParse(this.Text, out num))
{
this.Text = this.Text.Substring(0, this.Text.Length - 1);
this.Select(this.Text.Length, 0);
}
base.OnKeyUp(e);
}
}
}
|
|
|
|
|
Hi, I'd like to update an item from my collection. I used the code below but this calls the Dispose event which I'd like to avoid.
this.CurrentUser.Companies[idx] = comp;
So instead I'd like to use something like below which works and doesn't trigger the Dispose but seems inefficient with 4 calls made. Does that make sense? Can anybody please recommend a more efficient approach?
private void UpdateCompanyFields(int idx, Company comp)
{
this.CurrentUser.Companies[idx].BusinessName = comp.BusinessName;
this.CurrentUser.Companies[idx].Address.AddressOne = comp.Address.AddressOne;
this.CurrentUser.Companies[idx].Address.AddressTwo = comp.Address.AddressTwo;
this.CurrentUser.Companies[idx].Address.City = comp.Address.City;
}
|
|
|
|
|
You first line of code will not automatically "call the Dispose event" unless your Companies collection specifically does that when you overwrite an element - in which case there is probably a very, very good reason for it.
And your second code does not do the same thing at all - it overwrites parts of the class instance held by the collection which alters the instance throughout the app.
For example:
class MyClass
{
public int Value {get; set;}
public MyClass(int x) { Value = x;}
}
MyClass[] data = new MyClass[2];
MyClass x = new MyClass(333);
MyClass y = new MyClass(666);
myClass z = new MyClass(999);
myClass[0] = x;
myClass[1] = y;
myClass[0] = z;
myClass[1].Value = 111;
Changing x.Value will not affect the value in MyClass[0] and vice versa, changing the value of y will affect the value of myClass[1] and vice versa. Changing myClass[0] or z will affect both because they are the same instance.
I think you need to think a bit more carefully before you continue, and find out why the collection is calling Dispose - it implies the Company has important other info which needs to be replaced and Disposed, which your second code example does not do.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The real inefficiency comes from the memory management in the second instance. With your original code there is an object in memory already and this line
this.CurrentUser.Companies[idx] = comp;
simply copies the memory address of "comp" to the Companies array at index idx. However this code;
this.CurrentUser.Companies[idx].BusinessName = comp.BusinessName;
Looks at the length of comp.BusinessName, reserves the same amount of memory elsewhere, copies the contents of BusinessName into that memory, then assigns that memory address to Companies[idx].BusinessName. All that memory management makes that operation slow, and you are doing it multiple times.
There is nothing wrong with the dispose event being called, it doesn't make the code inefficient. Unnecessary memory management is more likely to be a cause of inefficiency.
|
|
|
|
|
COBOL has a MOVE CORRESPONDING that accomplishes what you want.
Internally, the compiler will still generate "4 moves". Why do you think that is?
And what part is "disposable"?
And how exactly is your code "calling Dispose"?
Or, are you bluffing?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
The Properties > Publish page of my App shows a Publish Version of 5.0.0.7.
When I use:-
Assembly assembly = Assembly.GetExecutingAssembly();
FileVersionInfo fileVersionInfo = FileVersionInfo.GetVersionInfo(assembly.Location);
it always gives 1.0.0.0.
How do I access the version number from the properties page?
|
|
|
|
|
public string AssemblyTitle
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyTitleAttribute), false);
if (attributes.Length > 0)
{
AssemblyTitleAttribute titleAttribute = (AssemblyTitleAttribute)attributes[0];
if (titleAttribute.Title != "")
{
return titleAttribute.Title;
}
}
return System.IO.Path.GetFileNameWithoutExtension(Assembly.GetExecutingAssembly().CodeBase);
}
}
public string AssemblyVersion
{
get
{
return Assembly.GetExecutingAssembly().GetName().Version.ToString();
}
}
public string AssemblyDescription
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyDescriptionAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyDescriptionAttribute)attributes[0]).Description;
}
}
public string AssemblyProduct
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyProductAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyProductAttribute)attributes[0]).Product;
}
}
public string AssemblyCopyright
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyCopyrightAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyCopyrightAttribute)attributes[0]).Copyright;
}
}
public string AssemblyCompany
{
get
{
object[] attributes = Assembly.GetExecutingAssembly().GetCustomAttributes(typeof(AssemblyCompanyAttribute), false);
if (attributes.Length == 0)
{
return "";
}
return ((AssemblyCompanyAttribute)attributes[0]).Company;
}
}
Note that is the Executing Assembly it fetches data for - i.e. the assembly that that specific code is compiled into. If that is a DLL used by the app - i.e. a code library - it will fetch the data for the DLL, not the original EXE that called it. For the original EXE assembly data, replace GetExecutingAssembly with GetEntryAssembly
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
AssemblyVersion still returns 1.0.0.0 despite the Properties > Publish page showing 5.0.0.7. That is with GetExecutingAssembly or with GetEntryAssembly.
Am I missing something?
|
|
|
|
|
Probably, yes. From here though it's difficult to tell what. 
Start by looking in the project Properties folder at the file AssemblyInfo.cs - copy and paste that so we can read it, along with the full path to the file - the version info is normally at the bottom.
Then show exactly the code you used, what it displayed, and tell us the location of the file it's in (the full path helps here as well)
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks, got it. I am getting the correct details from AssemblyInfo.cs.
I'll just have to update that and not rely on the automatically incremented Publish Version as on the Properties > Publish page. I'll keep looking for a way to increment the former.
|
|
|
|
|
I will develop a new application with this specification:
read only from a folder (txt, xml, csv)
read only from a given database
generate files (txt, xml)
read and write from/to another database
communicate with printing server
communicate with email server
connect to a Web Service (Migration)
I think that the best approache is DDD (or hexagonal) maybe both but I have some questions:
1- DDD vs hexagonal (I can't find the real difference)
2- parsing files like txt, csv ... must be in the infrastructure layer that's mean we must use the repository pattern but how?
3- I have only read for some data sources so why we don't use the CQRS pattern (Read model / Write model)
4- the new web service will provide us the same data as a txt file so how could test our app and hide the data sources?
5- how Anti-Corruption Layer pattern can be used for this migration (cvs,txt ---> web service)
|
|
|
|
|
For a trivial app, you're over-thinking this. Start with some "DFD's" (Data Flow Diagrams).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Basically, I agree with Gerry Schmitz that your question is a case of bringing up a lot of accidental complexity into question.
1. The goal of DDD is to model a complex domain with a lot of business rules. From your specs it doesn't sound like you have a complex business domain. It doesn't sound like you have a domain at all, what you do is just a couple of CRUDs and printing/sending emails.
2. How does something put into the infrastructure layer means that you MUST use a repository pattern? Why do you have to use repository pattern at all? There is a lot of argument that having a repository atop of ORM (if you plan to use one) is a leaky abstraction. Building repository atop of csv, txt generation? Sounds even more questionable.
3. Practicing CQRS means increasing the cost of synchronization between your read and write models? Why is it worth it? To practice DDD, which is the original motivation for CQRS?
4. Basically, you can test it with on a lot of different layers, namely e2e, integration, unit tests.
5. Anticorruption layer means that you have to protect your complex business domain during the integration with legacy service. Do you have a complex business domain worth protecting? I doubt it.
|
|
|
|
|
thx.
the application is a banking app.
it will deal with:account, customers, transactions and other
banking products.
I agree with Gerry Schmitz. I started with DFD and the business logic.
As I said before, I will perform a reading from different
types of data sources(db and file system) this is my app domain.
And for business domain: banking rules, control, security, continuity.
infrastructure:
- repository pattern (EF dbcontext) and uow
- repository for file system (helper parsers )
- repository for Web Services
web services and file system having the same output/input business logic.
DB for saving and checking.
Finally to enssure the continuity we have to process the older (File system) and the newer
data sources (Web service)
|
|
|
|
|
Thanks for clarifying. I believe for modeling some complex business domain like banking system DDD makes sense and what you've provided in your clarification post is a sound approach.
|
|
|
|
|
I'm hoping this is possible in C# as I'm currently starting to learn C#
A black box is a box that you don't know what is inside but you can feed the box data and get a result. The black box has conditions. For example you might have an black box called age where you feed in a persons age and the result is "Under age" is displayed.
I want to have a number of black boxes in a program where once the black box code is written then I can forget about the code in the black box. All I need to do is to feed the black box information and get a result.
I'm thinking that this can be done with the C# class system or maybe there is a better way.
Maybe this setup is possible with an "age" black box and an "account" black box:
age person1 = new age
account person1 = new account
etc
Brian
|
|
|
|
|
Start with a class for each box, and if you want a "true" black box, put those classes in a separate Assembly. That way, you can release the Assembly .DLL file and add a reference to that in your other code with no source code required.
The "black box" code can't be changed without the source, and if you really want to you can use an obfuscator to make the DLL file a lot harder to examine.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks OriginalGriff for your reply.
The purpose of having black boxes was not to protect the code but to make it easier to program and I could use one or more black boxes when writing another program.
I don't know a lot about DLL type fiies but are you saying put the black boxes into a DLL and have the program refer to the DLL file...or maybe have a DLL for each black box?
Brian
|
|
|
|
|
Either way. If they are related function, then the same assembly makes sense. If not, then separate them by functional groups.
A DLL file (a class library in Visual Studio) is a .NET file which is compiled and is identical to an EXE file, except it lacks an entry point (the "Main" function).
By putting black box code in a separate assembly, you release the compiled file and the inner workings can't be seen or changed by the users. Much the same as you don't normally look at or try to modify the mechanics of the string.Substring method in your code (though you can access the Reference Sources if you want a look at how .NET does it).
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Thanks for the info OriginalGriff.
I might have a closer look at how dll files are created in C#.
Brian
|
|
|
|
|
A "black box" is a "component" (class) with a "clean" explicit interface.
There are specific "properties and methods" (class members) that are explicitly made public for the sole purpose of interfacing with the component.
Contrast this with a component where EVERY member is simply defaulted to public so that there is no control over how the "internals" of the component are accessed.
It's a design strategy.
"Black Boxes" can be / have static members, much like the "Math" class.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
