orangemms + orangeinternet = ...

Recently got a Samsung Galaxy i7500. Android phone. Bought off German Ebay.

I'm with Orange UK. I'd managed to configure my old SEK800i to work for internet browsing and with MMS, but I think I'd setup separate entries for the two usual Orange APNs of orangeinternet and orangemms.

Anyway, I think I've just managed to merge the two on my i7500: I'm getting 'net access and I've received (and apparently just managed to send) an MMS.

So:

Under Settings / Wireless Controls / Mobile Networks / Access Point Names,

create a new APN.

Name: orange internet

APN: orangeinternet

Proxy: <Not set>

Port: <Not set>

Username: <Not set>

Password: <Not set>

Server: <Not set>

MMSC: http://mms.orange.co.uk

MMS proxy: 192.168.224.10

MMS port: 8080

MCC: 234

MNC: 33

APN type: Internet + mms

Authentication Type: Normal(PAP)

Don't forget to Save.

(I accidentally rebooted the phone after I'd done that swapping my SIM back in from the SEK800i.)

You're welcome!

Trojan Alert!

[This happened a couple of weeks ago. I've been "clean" ever since.]

I'm kind of confused as to exactly what my laptop was infected with, but I noticed that my laptop was smtp-ing mails all over the place (but mostly to Russia).

[I only noticed because I have a somewhat peculiar locally-running-my-own-smtp-server email setup - and whatever had infected me had determined that server to be a suitable relay for the odd message.]

Anyway, the obvious symptom was that the absolutely real services.exe process was connecting on port-25 and sending mail. (Lots of connections seen via "netstat -ao".)

I noticed that my hosts file had been tampered with; the often-dependable spybot-s&d found a few things (including sdra64.exe, IIRC) and then malwarebytes' anti-malware told me sysdiag.dll and ipcmd.dll (in system32) were problems and got rid of those for me.
[Microsoft's/SysInternals' ProcessExplorer showed me that those DLLs were infact what was being loaded up into the services.exe process to send the mail.]
AdAware and some other thing starting with super (superspyware-something or other?) didn't find anything. McAfee was finding nothing (and never found anything, even after I'd manually updated it to the should-have-been-auto-updating-but-was-actually-failing new version) - until after I'd uploaded sysdiag.dll to webimmune.net and got a patch file.
Online virus-scanners showed that maybe 20% of the products they used detected these DLLs were malicious at all - and none of the products seemed to agree on a problem-name.

I thought I was clean at that point. But no - after a while the DLLs were trying to come back. (With the patch applied, McAfee was blocking them - every half an hour or so.)

I'd googled and found a few references to some of these files, but none of the problem-descriptions really tallied with the problem I had. (Which was lucky, because by most accounts if I'd got these files on my system then I'd got some completely incurable virus!)

I was getting close to deciding to reinstall Windows - I'd wasted a couple of days on this and my project deadline wasn't exactly getting further away.

Anyway, I continued throwing all the (now varying) dll names that McAfee was warning me about into Google and the only web page that was consistently coming up was somewhere under prevx.com. It didn't give much detail (and I was even a little suspicious that it wasn't just a scare-ware site, given that their product seemed to cost) but after searching for a little comfort on PrevX I downloaded the "trial" product and ran a scan.

Lo! Four minutes later and this program's quick little scan revealed problems that hours of scanning with McAfee and all the other spyware progs I could find had got nowhere near. Rather marketingly-cleverly, the prog does the scan for free and then makes you pay for (most) removals. I paid up the 20 quid for a year's subscription.

Rather quickly, cleanly and successfully, Prevx3 sorted out my machine for me.

Now as a general rule I dislike paying for software. (In case you were wondering, this means either work pays, or I try to get away with free / open-source stuff - and not that I'm into nicking it. I'm not into the piracy angle - I do figure if it's that indispensible to me then I should buy it and reward someone for their efforts.)

It's probably something to do with having spent two frustrating days getting to the point, but I'm actually finding myself feeling proud and clever to have shelled out (my own money!) for prevx - and I think it's such a sleek and effective bit of software that I'm happy to recommend you pay for it too!

I've since seen some excellent support being offered on some forum or other and they also have a they'll-remotely-fix-your-machine and/or a give-you-your-money-back-guarantee too. So when the other (free) tools aren't doing it for you, let prevx have a quick look and then decide if a quick result is worth a few dollars/quid/euros to you...

Which control lost the focus?

Sometimes underneath all the abstraction that is the .Net framework, they take away stuff that you really want to know. My requirement was essentially that, for a load of textboxes on a Windows Form, when the user clicks on the one-and-only command-button I needed to know which control/textbox had the focus before the button was clicked.
Clearly I could manually code things in the OnLostFocus/OnLeave methods, or listen for LostFocus or Leave events on each of the controls, but that seemed like plenty of work and plenty ugly. (After all, I'm only interested when the user clicks on the button and the button's GetFocus / Enter events fire, so this functionality should belong to the button, right?)

The "Win32" event which the .Net framework is massaging into its own events does provide the control that's losing focus, apparently. And you can override the framework method, WndProc, that's way up the stack there somewhere.

Anyway, I'm working in vb.net at the moment so I've come up with something like what's below...
(I haven't necessarily worked out all the foibles, but it's certainly doing the basic job. I also haven't bothered synchronising access to the PreviousControl property - can't see when that's going to cause me an issue, but YMMV. BTW, Google tells me Microsoft Access had a PreviousControl property... hence the name.)

Public Class ButtonThatTracksPreviousFocus
Inherits Button

''' <summary>
''' This PreviousControl property holds the last control that was known to have focus before this button
''' received the focus. Note that where this button has the focus on an inactive window, when the parent
''' window activates the PreviousControl will end up being the last control to have focus on the
''' other form, it seems.
''' </summary>
''' <remarks></remarks>
Private _previousControl As Control

Public Property PreviousControl() As Control
Get
Return _previousControl
End Get
Set(ByVal value As Control)
_previousControl = value
End Set
End Property


Protected Overrides Sub WndProc(ByRef m As System.Windows.Forms.Message)

' First check to see if this message is related to our gaining focus. If it is, make a note of the
' window / control that's losing it.

If m.Msg = 7 Then 'This is the WM_SETFOCUS message (which tells us in WParam the "window" that's losing focus)
Try
' We don't expect errors, but in the event that we get them we can simply assume we couldn't
' find the control and otherwise ignore.
If Not IntPtr.Zero.Equals(m.WParam) Then
Dim ctrl As Control = Control.FromHandle(m.WParam)
If Not ctrl Is Nothing AndAlso Not (ctrl.Equals(Me)) Then
' Store a reference to the "lost-focus" control. Note that this could actually be on
' another form so client-code may need to take account of this!
Me.PreviousControl = ctrl
End If
End If
Catch
Me.PreviousControl = Nothing
End Try


End If

'Regardless, normal message processing is carried out...
MyBase.WndProc(m)

End Sub

End Class


Element's value-of.

Fool! Next time, remember not to put an xsl:value-of in a template that matches an element, or you end up with the concatenated text of all the element's sub-nodes in your output document. (Unless that's what you want, of course...)

Unfinished BizNess?

So I had a few BizTalk / rules engine business rules that I wanted to set up some unit tests for.  I'd been steered towards using BizUnit (in which I'll admit to having limited experience), and I was looking into the FactBasedRuleEngineStep.

Just what I needed, it seemed. But long story short, it doesn't quite work like what it oughta....

BizUnit's over on CodePlex, and though the latest code isn't in the source repository, it is included as part of the downloadable MSI.  With a little bit of looking through the  code (expedient, what with the help file being one of those overly literal types that explains that the "WidgetFooStartDate parameter" is the "Parameter indicating the date on which the Foo Widget starts", and what with the rest of the web seemingly only proving that any other people trying to use this particular "step" can't use it), I not only got the policy to fire but also got an XML file and an instance of my custom helper-class passed in.  An output file gets created by the rules engine at the location specified by the <debugtracking> element, and it was all starting to look good.

But...

I can't find any evidence that the <resultfilepath> does anything (and it certainly doesn't seem to).  Your processed document / documents *are* output, but seemingly only to the "Context's" log (which seems by default to be the [nUnit] console).  I imagine you could redirect that output elsewhere, but I didn't really look very hard what with not being in the mood to bother parsing the output to extract my result XML.

I couldn't build the BizUnit source as I was missing some Office interops and some MQ (or was it MSMQ?) dependencies (and again, I wasn't of a mind...), but there looked to be a nice little way to intercept the output-facts just by implementing my own class that implements the IValidatorStep interface (wozzit?).... but oh no, it seems that that's only going to get executed if the DocumentType is "UBS.CLAS.PoC.Schemas.INSERTS".  By the code-comment's own admission, this was a //HACK, so I can only assume it was the document type that BizUnit's author/s needed to test for.

Checking the source code (similar if not identical for this "step" in both 2.3 and 3.0) it appears that there's a unit-test to test the FactBasedRuleEngineStep.  But it also appears to have been commented out...

And one last problem:  no evidence found that the takeFromCtx attribute does anything for this particular fact (though I'd kinda given up by then).

So okay, that might have come off as a bit of a rant.  I realise that a man called Kevin threw this thing out into the world for free, that he's probably not actually paid to work on this thing and that I've certainly paid nothing for it.  Obviously the source is available, so I could have dug in and fixed this issue myself, but a custom fork of an open-source project isn't the kind of legacy I like to leave in a client's source-control system.  (I'm not inclined to submit a patch to the project itself after seeing a few others on CodePlex that appear to have been awaiting approval for a year or more...)  Anyway, my point is:  Don't try to use the FactBasedRuleEngineStep to test your rules and expect it to work.

[I ended up coding something along these lines....

TypedXmlDocument typedXmlDocument = new Microsoft.RuleEngine.TypedXmlDocument("Your.Namespace.Plus.Schema.Name.Plus.Root.Element", xmlDoc);

Policy policy = new Microsoft.RuleEngine.Policy("ContactPointLoad");

//Also need to supply a CustomXmlHelper fact!

object[] args = new object[] { typedXmlDocument, new CustomXmlHelper() };

policy.Execute(args);

policy.Dispose();

return (XmlDocument)typedXmlDocument.Document;

]

Hope that saves a googling-someone a bit of working it out for themselves...