Code below is not working as expected to detect if it is in design mode (VS.Net 2003 - Control Library):
if (this.Site != null && this.Site.DesignMode == true)
{
// Design Mode
}
else
{
// Run-time
}
It is used in a complex user control, deriving from another user control and including other user controls on it.
Is there another way to detect design time in a VS.NET 2003 or what is the problem with the code above?
DesignMode won't work from inside a constructor. Some alternatives (not sure if they work in 1.1) are
if (System.ComponentModel.LicenseManager.UsageMode == System.ComponentModel.LicenseUsageMode.Designtime)
or
call GetService(typeof(IDesignerHost)) and see if it returns something.
I've had better luck with the first option.
I guess you could use HttpContext.Current == null as described at http://west-wind.com/weblog/posts/189.aspx
In .Net 2.0 there's Control.DesignMode (http://msdn.microsoft.com/en-us/library/system.web.ui.control.designmode.aspx). I guess you have a good reasons to stay on VS 2003 though, so upgrading might not be an option for you.
Update If you are doing Winforms, Component.DesignMode (http://msdn.microsoft.com/en-us/library/system.componentmodel.component.designmode.aspx) is the right way to check. Though, if this.Site.DesignMode doesn't work properly, Component.DesignMode might not work as well, as it does exactly the check you are doing (Site != null && Site.DesignMode).
This might be a long shot, but are you sure that your base control does not override the Site property?
Related
Why does MouseEvent.toElement return Node?
I'd assume it should return Element, or the method should be renamed toNode.
As it stands, having the dart editor warn me about accessing the style property when I write the following is less than ideal:
event.toElement.style.textDecoration = "line-through";
I believe it's called toElement() to keep it aligned with what we have already in the DOM/JavaScript land. It was named by Microsoft long ago and has been adopted in several browsers today. So, I think in Dart we wanted to keep the same name.
However, whether we should annotate it to return Node or Element, that's a good question. I believe in almost every (if not all) cases the returned object is indeed an Element and it would be nicer if it was typed to return an Element. However, there may be corner cases where it actually returns a Node (remember, elements extend nodes). With quick testing, I couldn't find any such case. Maybe with manual event firing.
Maybe the Dart engineer behind this choice can shed us some light.
In the bad old days in my codebase we relied quite heavily on event requeuing, which I suspect worked due to implementation details in ICEfaces or MyFaces rather than standard-specified behavior. One thing we used to do frequently was this kind of thing:
<ice:inputText value="#{bb.frequency}" valueChangeListener="#{bb.valueChanged}"/>
The goal is to arrange for retune to be called after setFrequency whenever the frequency changes.
Then we had some fairly disgusting code in the backing bean which would requeue the event. It usually looked something like this:
class BB {
// this happens first, thanks to UPDATE_MODEL_VALUES
public void setFrequency(Frequency f) {
this.model.f = f;
}
public void valueChanged(ValueChangeEvent event) {
if (event.getOldValue().equals(event.getNewValue())
return; // nothing changed, so leave
if (FacesContext.getCurrentInstance().getPhaseId() != INVOKE_APPLICATION) {
OurMagicEventUtils.requeueEvent(event, INVOKE_APPLICATION);
}
else {
// do the post-setter work here (the setter happened recently during
// UPDATE_MODEL_VALUES so we're up-to-date by here
this.model.retune();
}
}
}
This isn't a good way to live. I haven't found a reliable way to requeue events for later phases and it clearly isn't the kind of thing people do. I see two solutions:
Move the retune intelligence to the BB#setFrequency method.
I can't get away with this in many cases because I'm directly addressing a lower-level model class and I don't want to disturb its behavior for other clients.
Create a custom component and move the logic into the setFoo method there.
I don't love this because there are a lot of issues with Mojarra and custom components when embedded in other containers. It also seems like overkill for what I need to do—I literally just need to call retune after setting some properties.
Create backing beans for everything. Delegate most methods directly to the inner thing, but catch setFoo and perform the retune there. This is very similar to what we used to do, and it means a lot of boilerplate, wrappers, and glue code, so I don't love it.
In my mind I imagine something like this:
<ice:inputText value="#{bb.frequency}" afterChange=#{bb.retune}"/>
but that obviously doesn't work, nor would attaching an <f:actionListener> since that requires a class name but has no association to whatever you're currently doing, and besides it can only be set on UICommands which UIInputs are not.
What's the elegant/correct way to solve this dilemma?
As you're using JSF2 already, just use <f:ajax>.
<ice:inputText value="#{bb.frequency}">
<f:ajax listener="#{bb.retune}"/>
</ice:inputText>
with
public void retune(AjaxBehaviorEvent event) { // Note: the argument is optional.
// ...
}
This will be invoked during invoke action phase when the HTML DOM change event has occured.
I would like to change the GraphicsProfile to Reach. As told to me in another answer the solution would be to use:
graphics.PreparingDeviceSettings += (s, e) =>
{
e.GraphicsDeviceInformation.GraphicsProfile = GraphicsProfile.Reach;
};
But my e.GraphicsDeviceInformation does not contain the GraphicsProfileproperty.
I don't understand how two implementations of the same class are present in MonoGame.Microsoft.Xna.Framework and MonoGame.Microsoft.Xna.Framework.Graphics.
The one in ...Framework is the one used by PreparingDeviceSettingEventArgs but the other one contains the property I need: GraphicsProfile.
(I feel like I am missing something very stupid here...)
It is currently not supported. Simply create an XNA project for PCs.
But I then wonder how I could do if I want to support an Android build (MonoGame) which would not fit with the High profile.
I am trying to write an ADO Database profiler in Delphi 7.
it is part of a Delphi project.
I am using OnExecuteComplete event, but on some PCs i get "MSADO15.DLL" Access Violation error.
I have researched and underestand some win version is incompatible or damaged or has different version..
that AV error happened when i use parameters[i].value property of "Command"..
then i decide to write a different type,
now i need a refference to an object who called OnExecuteComplete event in ADOConnection.
if i can reach it, problem will be solved.
i use "Command" and "Recordset" refferences to compare by all of ADO object who linked by this ADOConnection, but some ADO objects has no Recordset..
is there a way to find who fire that event? like Sender?
I could not make out if you are in .Net or not, but in .Net it's easy. Use System.Diagnostics.StackTrace to see the whole stack of calls that lead to your event.
For native code there will probably also be a way to get a stacktrace if you compile in debug mode. It's quite some time since I've written Delphi (or Pascal) code. You could also try profiling with the free AQTime standard which works well with Delphi (both native as well as .Net) which also has a call-graph feature.
i solve it!
i write 2 derrived classes, from ADOQuery and ADOStoredProc.
then i publish Command property of them.
by force convert StoredProcedure to new class, i reach to command prop and compare that by command object of event!
problem solved!
thank you all.
Only WindowsXP,Windows 2003 has problem with "MSADO15.DLL" Access Violation error after read Parameters[i].Value and show recordset. Windows7 has not this problem. Use WillExecute event - it work fine everywhere. In ExecuteComplete you may get recordsAffected from recordset (RecordsAffected variant work wrong). You can get Parameters[i].Value later if Save Parameters to Variant variable and read it after visual components show recordset - use OnButtonClick for example or Timer event. This BUG not fixed at all Delphi versions - and in DelphiXE2 too..
The Sender should give you a clue, if it is not nil. Cast it to TComponent and use its Name property to find out which component fired it:
ShowMessage((Sender as TComponent).Name);
If Sender is nil, a stack trace might help.
Update
Apparently there is no Sender parameter. In this case, the Connection must be the class that fires it, so get its name and other data. You get enough parameters to find out what is happening.
We are using MEF to customize certain functionality of our ASP MVC application. We are using .NET 4.0, and SQL Server 2008. We have run into some very strange behavior when using EF4 and a LINQ statement to a view inside a MEF assembly.
The code below will timeout when executed as part of the imported assembly using MEF.
It will run in less than a second when it is pulled out and executed in the main assembly.
If the date range is set to one day the MEF implementation will eventually finish in about 15 seconds.
If we use a table instead of a view it will work fine in the MEF implementation <1 sec.
The code below and the view works flawlessly everywhere except when executed inside the MEF code.
Does MEF introduce any special limitations or problems when EF4 is used in a MVC Web application? We can find a work-around to this problem, but I'd like to know if this is a symptom that we are using MEF wrong?
DateTime startDate = DateTime.Now.AddDays(-30);
DateTime endDate = DateTime.Now;
var _Items = dto.ClientContext.vwItemLists.Where(c => c.CreatedOn > startDate && c.CreatedOn <= endDate);
_context.TotalItemsMatched = _Items.Count();
The problem is likely occurring due to a bad cached execution plan. See this similar issue.
This answer has worked for me in the past, when I'm pretty sure some sort of one-time corruption was the culprit, but note the comment that this is a short-term fix and in many cases the issue might crop up again if you don't resolve the root of the problem.
He refers to this article, which is unfortunately pretty heavy reading, to help you try to identify why a bad execution plan was cached in the first place.