|
Hi,
I have an ASP.net application, which gets data from Database. In that it gets datetime from data base. In database it contains milli seconds as well. But when it comes to .Net milli seconds are removed. So when I compare these dates, they are not equal. Is these any way to hold the date time field as it is in the database and send it to another stored proc for comparision.
thanks in advance.
Thanks & Regards,
Abdul Aleem Mohammad
St Louis MO - USA
|
|
|
|
|
Your problem more look like conversation of date time from database to your .net application. Please check how you fetching value from database to .net application.
|
|
|
|
|
Try using in this format :
ddMMMyyyy HH:mm:ss.ff
Success is the good fortune that comes from aspiration, desperation, perspiration and inspiration.
|
|
|
|
|
Hi there
I'm looking for the an answer for this:
why "myFlickr.UploadPicture("C:\h.jpg")"
the value is nothing, that path is rigth. So when I stop the VS.net it take a few seconds, and the Autenticated is True. I guess the Apikey and the Secret y rigth.
any idea?
Saludos
|
|
|
|
|
HI THERE
This was very simple to fix it.
FILEUPLOADER.SAVE("C:○\H.JPG").
Then I use de file in the path of server, that's all for this.
Saludos
|
|
|
|
|
I am create crystol report in asp.net in visual studio 2010 but crystol report toolbar Print Button Not working in Google chrome brouser
How to fix this error.
|
|
|
|
|
|
I am trying to get the value of a textbox once the user clicks the submit button.
I can get it using the following code but is there a better way? It makes no sense to me to actually view the source code to get
ctl00$ContentPlaceHolder1$DailyReceipts1$rpt_Ticket$ctl01$rpt_TicketDetail$ctl01$txt_qty
instead of coding to get it. Any help will be appreciated.
CODE in FRONT
<asp:ImageButton ID="imb_EditDetail" runat="server" AlternateText="Update Receipt" ImageUrl="edit.gif" OnClick="Update_TicketDetail" />
<ajaxToolkit:ModalPopupExtender ID="ModalPopupExtender1" runat="server"
TargetControlID="imgEditDetail"
PopupControlID="pnl_EditQty"
BackgroundCssClass="modalBackground"
DropShadow="true"
OnOkScript="ok()"
CancelControlID="Btn_CancelEdit" />
<asp:Panel ID="pnl_EditQty" runat="server" CssClass="modalBox" Style="display: none;" Width="300">
<asp:Panel HorizontalAlign="Center" ID="Panel2" runat="server" >Edit Quantity</asp:Panel>
<asp:Label ID="lbl_Name" runat="server"></asp:Label><
<asp:TextBox ID="txt_qty" runat="server" ></asp:TextBox>
<asp:Button ID="Btn_Edit" runat="server" Text="Edit" Width="55px" OnClick="Btn_Edit_Item_Click" CausesValidation="true" Itm_idx="" ticket_idx="" history_idx="" old_qty="" Control_id="" />
<asp:Button ID="Btn_CancelEdit" runat="server" Text="Cancel" Width="55px" buttonAction="submitButton" />
</asp:Panel>
CODE BEHIND
protected void Btn_Edit_Item_Click(object source, EventArgs e)
{
string id = ((Button)source).CommandArgument.ToString();
string idx = ((Button)source).Attributes["Itm_idx"].ToString();
string ticket_idx = ((Button)source).Attributes["ticket_id"].ToString();
string history_idx = ((Button)source).Attributes["history_id"].ToString();
string oldQty = ((Button)source).Attributes["old_qty"].ToString();
string controlID = ((Button)source).Attributes["Control_id"].ToString();
string detail = ((Button)source).Attributes["detail"].ToString();
string itemQtyEdit = Request.Form["ctl00$ContentPlaceHolder1$Daily" + detail + "1$rpt_Ticket$ctl" + controlID + "$rpt_TicketDetail$ctl0" + idx + "$txt_qty"].ToString();
}
modified on Monday, February 28, 2011 8:14 AM
|
|
|
|
|
First, please format any code snippets you post using the "code block" toolbar item. This improves the readable and increases the chance you will actually get an answer. Read this[^]
Second, read some books on ASP.NET and C#.
string idx = ((Button)source).Attributes["Itm_idx"].ToString();
This is a useless conversion as Attributes are already strings and ToString() is a waste of processor cycles.
ctl00$ContentPlaceHolder1$DailyReceipts1$rpt_Ticket$ctl01$rpt_TicketDetail$ctl01$txt_qty
This is the clientId of the control in question and is not how you access a control in the code behind. You simple use the ID, txt_qty in this case. You certainly don't access it via the Form property.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
Thanks but I cannot access txt_qty unless I use the Form property. Trust me, I would love too. Can you point me on the right direction?
|
|
|
|
|
Robert Espindola wrote: I cannot access txt_qty unless I use the Form property
You will have to explain this further. ASP.NET server controls are accessible by their IDs in the code-behind. Have you started with a sample, just a simple form?
BTW, you can edit your original post to format as I have suggested.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
i would simple add the values on the session or on the hidden field that can be updated on the click of your submit button.
Vuyiswa Maseko,
Spoted in Daniweb-- Sorry to rant. I hate websites. They are just wierd. They don't behave like normal code.
C#/VB.NET/ASP.NET/SQL7/2000/2005/2008
http://www.vuyiswamaseko.com
vuyiswa@its.co.za
http://www.itsabacus.co.za/itsabacus/
|
|
|
|
|
I'm fairly new to dependency injection but it seems like a proper DI implementation will be fairly complex.
For example, DI requires a centralized class that manages the configuration and resolves the dependencies at runtime.
DI is also based on the concept of using interfaces. For example, a SpecialLogger should use an ILogger interface.
The centralized DI manager class will need to register types - for example, associate ILogger to SpecialLogger.
SpecialLogger will also need to implement the ILogger interface so SpecialLogger can be used through the DI ILogger interface.
Therefore, it seems like a sln using DI will need multiple projects to support DI. Here is an example for logging:
* MyCompany.MyDivision.Framework.DI.Management - this would have the DI manager where dependency types are registered and resolved at runtime
* MyCompany.MyDivision.Framework.Logging - this would have the implementation of a logging class. The main logging class would need to implement ILogger.
* MyCompany.MyDivision.Framework.DI.Interfaces - this would have the ILogger interface.
Interfaces would need to be stored in a separate class library from the DI manager because both the DI manager and SpecialLogger use the ILogger interface. Since the DI manager associates SpecialLogger to ILogger a circular reference would be encountered without a separate class library to store the ILogger interface.
Does this sound like a reasonable assessment? Like I said I am just learning DI so if you can share any real-world experience with a DI implementation that would be appreciated.
|
|
|
|
|
The DI framework is usually a component of the application layer (in my experience) e.g If you had an ASP.NET MVC App and you were using structure map, its your front end application that would reference structure map, the rest of your code below that stack does not need to know about the DI container becuase its dependencies would be resovled by the main application (E.g MVC)
Then the rest of your dependencies etc.. you could seperate the interfaces from the concrete classes, but I would only do that when its required. You could start with a simple MyCompany.MyDivision.Framework.Logging project that contains the ILogger and the SpecialLogger.
Becuase the DI container is just references in the top of the stack (e.g the MVC app) it already has references to the components below it, so no circular reference is created.
If you find yourself reference the DI container lower down the stack then you may run into problems, there are usually more specific services you can implement for resolving things the DI container could provide.
e.g Lets Say you had the Logging assebly, a Domain Layer assembly, and a front end project, and the requirements where for the front end project to have references to the domain layer and logger, but you dont want interdependencies between the two:
Then lets imagine you had a bunch of repositories that needed resolving in your domain data access layer, that could be a IRepositoryRegistry interface, but it could be implemented in the app up the stack to look at the DI container to return a repository. There would be no need for your logging assembly to ever use IRepositoryRegistry, so you don't end up with dependencies between those sort of assemblies.
James
James Simpson
Web Solutions Developer
www.methodworx.com
|
|
|
|
|
So just using a very simple example. I would create the UnityContainer and register the FileLogger like this:
UnityContainer uc = new UnityContainer();
uc.RegisterType<ILogger, FileLogger>();
Then in the same code block I would resolve the ILogger for the dependent classes like this for an Order class:
uc.Resolve<Order>();
To do this I would need to define an Logger property on the order class like this right?:
public ILogger Logger { get; set; }
From what you are saying it sounds like an important design goal of dependency injection is that a central class does all of the injection and the classes being injected should not need to know about the container. Is this correct?
|
|
|
|
|
I got the example in my above post to work.
Basically, uc.Resolve<order>() returns an Order object with the Order ILogger set to FileLogger.
This is great but how can I persist this dependency?
In the following example I would expect the FileLogger to be persisted as the ILogger to be used for all instances of the Order object:
UnityContainer uc = new UnityContainer();
uc.RegisterType<ILogger, FileLogger>();
uc.Resolve<Order>();
Order o = new Order();
ILogger logger = o.Logger;
However, in this example, although the FileLogger is associated with the object returned from the Resolve<order> method, the subsequent Order instantiation does not have a reference to FileLogger (null).
This seems to reflect the most typical scenario because the DI should be done once and then code within the Order object will run independently and try to access the Logger from within the Order object.
Are there some sort of settings that I'm missing to be able to persist this configuration?
|
|
|
|
|
In the example you provided you are not initializing the Order class via the container.
uc.Resolve<order>() creates an instance of the Order and then resolves its dependencies
This is why you would end up with more specialized services to initialize the objects, that are typically implemented with the container.
e.g Lets, say Order is an Entity in a domain model, you have several options about how you initialize a new one, a typical way is to have a factory, e.g IOrderFactory.Create(). Lets say for the sake of argument you are using ASP.NET and you are using dependency injection to initialize your controller paramerters via a custom controller factory (if you are unsure about that, basically a DI container is supplying dependencies to Controllers)
You would have a dependency to IOrderFactory in your controller constructor which would implement create as:
return uc.Resolve<order>();
Your order factory would be injected to your controller, and you can call orderFactory.Create() to get a new instance.
Or..
Inject the DI container into your controllers and just always call .Resolve. But I dont like to know about the DI container anywhere in my code, I prefer to have proper named services. e.g IOrderFactory is explicit, it is a Factory for creating Order objects, but by just handing a reference to your DI container everywhere you are actually hiding the dependencies. (e.g from the constructor parameters, it is not obvious what dependencies are going to be used and why)
Also - (off topic), with the example you specified above, if Order is an entity in your domain model, and you are attempting to add logging functionality to it, it is better to use a Dynamic Proxy pattern to acheive this (or) Aspect Orientated programming. It is not a dependency of the Order object to have logging functionality, it is more likely a dependency of your infrasturcture. So rather than cluttering up your order object with stuff it does not need, you can inject a Logging mechanism transparently using something like Castle Dynamic Proxy (?) You will still need to get the object from some sort of factory, but it will make your classes much cleaner.
James Simpson
Web Solutions Developer
www.methodworx.com
|
|
|
|
|
Thanks James - You know your stuff
|
|
|
|
|
Hi James - This is the solution that you provided in your last post:
"You would have a dependency to IOrderFactory in your controller constructor which would implement create as: return uc.Resolve();"
Can you please provide a constructor code block for this?
This is the closest constructor I can infer from your post:
public OrderController(IOrderFactory creator)
{
uc.Resolve();
}
1. The factory does the class creation but it's included as a param. So there is another layer of abstraction that sets the appropriate IOrderFactory? What is this additional layer of abstraction and where is it located?
2. So uc.Resolve() should be used to resolve the domain objects used by the controller? I'm assuming that the dependencies are passed down through the interface param?
I'm still trying to figure out the pieces and interaction for this.
|
|
|
|
|
I think my examples are probably more confusing than they should be. if you develop your layers without thinking about the DI layer, just rely on getting dependencies into objects via a constructor, you can add the DI container later.
Typically the container would resolve the controller (transparent to your code) and inject an instance of a factory, or repository, or service.. or whatever is needed
Then in the example of the IOrderFactory, the create could also be implemented to resolve the Order object from the same container
But, if the Order is an Entity you should be using a IOrderRepository to manipulate it, and this can include the factory method Create()
The key is to not architect your layers with the DI container in mind, just use the right sort of services to get the job done, at the end of the day they *might* be implemented using a DI container, they might not... if you working with this sort of technology your probably trying to unit test too, so if you get this right, it will probably lead you down the right path anyway.
Google sturcture map ASP.NET MVC implementation there are some good articles that demonstrate the idea behind a simple DI container and MVC.
Good luck
James
James Simpson
Web Solutions Developer
www.methodworx.com
|
|
|
|
|
using System;
using System.Collections.Generic;
using System.Collections.Specialized;
using System.Text;
using System.Configuration;
using USCG_SSO.Interfaces;
namespace USCG_SSO
{
public class ObjectFactory<T> : IObjectFactory<T>
{
public ObjectFactory() { }
public T getInstance()
{
return getInstance(null);
}
public T getInstance(object[] initializationParameters)
{
NameValueCollection appSettings = ConfigurationManager.AppSettings;
Type type = Activator.CreateInstance(typeof(T), initializationParameters).GetType();
if (initializationParameters == null)
{
switch (type.ToString())
{
case "USCG_SSO.ServiceUser":
NameValueCollection appSettings = ConfigurationManager.AppSettings;
initializationParameters = new object[]
{
appSettings["ADUserID"],
appSettings["ADUserPassword"],
appSettings["ADFieldName"]
}
break;
case "USCG_SSO.ActiveDirectory"
initializationParameters = new object[]
{
new ObjectFactory<ServiceUser>().getInstance(),
new ObjectFactory<CurrentUser>().getInstance()
}
break;
default:
break;
}
}
return (T)Activator.CreateInstance(typeof(T), initializationParameters);
}
}
}
Assuming: USCG_SSO.ActiveDirectory object requires a ServiceUser object and a CurrentUser object to be passed in it's constructor, and USCG_SSO.ServiceUser object requires values retreived from the .config file in it's constructor. If you call
IActiveDirectory ADObject = new ObjectFactory<ActiveDirectory>().getInstance();
You would obtain an ActiveDirectory object complete with all of it's dependencies. Now, granted, this isn't as "fancy" or extensible as an actual IoC framework (there's no registration of dependencies, auto-resolution, etc.), it is, however, a complete, very simple IoC/DI implementation.
Kevin Rucker, Application Programmer
QSS Group, Inc.
United States Coast Guard OSC
Kevin.D.Rucker@uscg.mil
"Programming is an art form that fights back." -- Chad Hower
|
|
|
|
|
Hi,
I would like to know if you processed credit card payment on your ASP.NET website or one of your clients ASP.NET website..
which company you used to do it? did they have ASP.NET API?
which payment processor your recommend?
|
|
|
|
|
|
but the problem with Paypal, they don't allow international uses.. it's only for US as they told me in their email sent to me.
|
|
|
|
|
jrahma wrote: did they have ASP.NET API?
Usually no one will provide .NET specific APIs. It will be web services which can be invoked using wide variety of programming languages.
Best wishes,
Navaneeth
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
