I'm struggling with navigation in asp.net mvc and URLs.
When you are visiting your profile at facebook, the url is facebook.com/yourusername.
At your profile there is a menu with the following links: Timeline, About, Friends etc.
When you click on one of these links, for example Photos, the URL is changed to facebook.com/yourusername/Photos, and the photos are rendered. The menu described above are still there, and so also the profile picture and the cover picture. Its like a partial view has rendered viewing the photos.
I want to accomplish this effect in my project, but I don't know how to do it. I have tried to do it with Partial view but the problem is that the URL is not changed when the partial view is rendered.
Anyone can help me with this? How should I structure it?
No I am not, do you have a suggestion on another way I can check?
The code under the Exception snapshot, always has the same error message with the Parameter is not valid at
at System.Drawing.Image.FromStream(Stream stream, Boolean useEmbeddedColorManagement, Boolean validateImageData)
at System.Drawing.Image.FromStream(Stream stream)
at Updator.PictureUpdater.btnViewPicture_Click(Object sender, EventArgs e) in c:\Users\xxxx\Documents\Visual Studio 2012\Projects\Updator\Updator\Form1.cs:line 245
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.DispatchMessageW(MSG& msg)
at System.Windows.Forms.Application.ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr dwComponentID, Int32 reason, Int32 pvLoopData)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoopInner(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.ThreadContext.RunMessageLoop(Int32 reason, ApplicationContext context)
at System.Windows.Forms.Application.Run(Form mainForm)
at Updator.Program.Main() in c:\Users\xxx\Documents\Visual Studio 2012\Projects\Exchange Picture Updator\Updator\Program.cs:line 19
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String args)
at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence assemblySecurity, String args)
at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
I figured it out, I had to build my own byte array and not use memory stream. Memory stream was corrupting the file and making it an additional 28 bytes. I'm not sure why this wasn't on the internet, as it seems 100's of people encounter this?
Thanks for pointing me in the right direction.
byte imgBytes = null;
List<byte> imgBytesList = new List<byte>();
object imgObj = null;
Image img = null;
foreach (PSObject obj in exResults)
imgObj = obj.Properties["PictureData"].Value;
foreach (byte byt in (dynamic)imgObj)
imgBytes = imgBytesList.ToArray();
using (var ms = new MemoryStream(imgBytes))
img = Image.FromStream(ms);
pbxDisplayPicture.Image = img;
I have an application that uses a COM object to make a connection to an application. I need to make sure that when my application ends that I call the EndSession and CloseConnection methods of this COM object. I was reading this article: Implementing IDisposable and the Dispose Pattern Properly[^] as I think this is what I would need to do to make sure my closing code always gets called, but it doesn't seem to happen when I stop debugging. The application that I am connecting to still thinks my program is connected. It seems like when I stop debugging (or if I have a program crash, that the Dispose methods don't get called. I also tried to add a Finalizer but that causes a System.Runtime.InteropServices.InvalidComObjectException stating that the COM object that has been separated from it's underlying RCW cannot be used.
protectedvirtualvoid Dispose(bool disposing)
if (_Session != null) // _Session is the COM object.
_Session.EndSession(); // These are the COM functions to close and end the
_Session.CloseConnection(); // session that must be called, but this is where I
_Session = null; // get the InvalidComObjectException.
disposed = true;
~SessionConnection() // This was added, which seems to be the root cause of the COM exception
I'm not sure what is the best way to ensure that the EndSession and CloseConnection methods of my COM object get called even if my program crashes or I stop debugging.
When you launch the code from inside Visual Studio, it's launched, the debugger is attached and you debug on your merry way. If you hit Stop inside Visual Studio, your code is stopped, wherever it is, and removed from memory. Your Dispose code never gets executed.
The only way to make sure it does is if you exit your application as a user would, gracefully.
That's what I was going to say!
The only thing I'd add is that the same thing will happen if you use Task Manager to kill the process. So if this is causing a problem with "Stop debugging" it'll also cause the same problem if the user terminates the app.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
I never knew that about the debugger, thanks! But then does this mean that GC doesn't do any cleanup? Or is Visual Studio maintaining the information so it knows to release any allocated memory? Is this something to do with the VS Hosting Process? If I open a file within a using statement, it seems like stopping the debugger is still releasing the file handle (at least I think so, I'm still very new).
Are there any recommendations / best practices when dealing with situations like this?
There is no cleanup of the orphaned COM stuff. It's just left hanging. When the code is stopped abruptly, the GC doesn't even run. Your process is stopped cold and the memory the app and its data was occupying freed and returned to Windows.
The GC cannot clean up non-managed resources anyway. It can only cleanup managed stuff. The closest it can get is to free up the managed COM-wrapper that's is hanging onto the unmanaged COM references, but this doesn't free up those unmanaged resources. They are just orphaned.
The debugger doesn't release anything at all. It's just attached to the process, not executing or controlling it in any meaningful way.