New editor version for testing

[SpeechCenter]

I encountered a problem when closing a plugin window and trying to reopen it.

Fixed.

There's still one odd problem. If I use the filter in my plugin and I close and reopen the window, the filter appears as if it's there, but the grid displays all the lines. This is not what's happening in previous AGS. I couldn't find an obvious place in my code where I'll do that behavior, but obviously there is some kind of event chain that will. Are you sending any events when reopening and what is the difference here and with AGS 3.2.1?

Some Windows: output, find results and call stack have an 'x' to close that pane info (was there before the change), but the docking window already has this, so I don't think it's needed, the whole gray band can be removed and provide more screen real-estate

Removed the extra header. For some reason when you start it, there's still an empty line there, but once you dock it out and in again it goes away.
I have no idea why, might be a bug in the docking suite.

Sounds like a resize problem, did you try to anchor the inner control instead of docking?

Scripts - It's a good idea to group the script and header. I think it's better to have the script open when double clicking the parent (and then not expand when double clicking). In the majority of the cases developers would like to edit the script and could expand to edit the header now there's an extra step to reach it.

I didn't find a simple way to do this. I could open up the editor but not avoid the expand. The problem is that the OnBeforeExpand event is triggered before the double click event and doesn't have a distinction between an expand caused by a double click and a regualr expand. So it's either going with windows messages (and I don't want to go there due to Mono compatability issues) or using timing calculations, or detecting the click location and deducting if the + was clicked or not, all of those are messy hacks and I didn't think the feature was important enough to justify it.

I hear you, very annoying GUI stuff. I just think you'll need to at least open the script on double click even if you do expand. Maybe it's best if you get game developers to review this, I think they won't like the extra step required to reach the script.

[tzachs]

New version in first post.

There's something I wanted to have for a long time (unless already implemented): a keyboard shortcut to switch between script header and source. Is there one? If not may that be added?

Done. Use Ctrl+M to switch ('M' for Matching script or header).
This will be the last feature I'm gonna implement for this version that's not directly related to something I did. I want to just concentrate on fixing bugs from now on.

tzachs:  I have been experimenting with docking to see two files side by side (.asc and .ash for example).  It's really nice to be able to do that but I can only get one file in the second editor pane.  Would you consider adding a feature to your version that would allow two multi-tab editor panes.  That would be a great feature to have, IMHO.

This feature is already there!
Every pane can behave as a multi-tab pane if you drag more than one document to the middle of it.
The only difference is that the tabs are in the bottom and not on top.
See this image as a proof:

There's still one odd problem. If I use the filter in my plugin and I close and reopen the window, the filter appears as if it's there, but the grid displays all the lines. This is not what's happening in previous AGS. I couldn't find an obvious place in my code where I'll do that behavior, but obviously there is some kind of event chain that will. Are you sending any events when reopening and what is the difference here and with AGS 3.2.1?

Hmmm, it's very hard to tell. There's a Refresh called on the form that happens when you show it that I think wasn't there before, but I tried to remove it and it didn't seem to solve the issue.
Also, I don't call Show on the form, but on the DockContent which is implemented in the Docking Suite, I don't know how it works there.
When closing I just hide the form, which as far as I know is how it worked in previous versions...

Sounds like a resize problem, did you try to anchor the inner control instead of docking?

I didn't try cause I figured out the problem, it was docked as Bottom and not as Fill. It's now fixed.

I hear you, very annoying GUI stuff. I just think you'll need to at least open the script on double click even if you do expand. Maybe it's best if you get game developers to review this, I think they won't like the extra step required to reach the script.

Ok, feature added, the new version opens the script on double click while still expanding it.
And btw, I believe most of the people reading these threads are game developers..

[Alan v.Drake]

Nice job tzachs. I can't wait to see all of this merged on the repository.

- Alan

[SpeechCenter]

There's still one odd problem. If I use the filter in my plugin and I close and reopen the window, the filter appears as if it's there, but the grid displays all the lines. This is not what's happening in previous AGS. I couldn't find an obvious place in my code where I'll do that behavior, but obviously there is some kind of event chain that will. Are you sending any events when reopening and what is the difference here and with AGS 3.2.1?

Hmmm, it's very hard to tell. There's a Refresh called on the form that happens when you show it that I think wasn't there before, but I tried to remove it and it didn't seem to solve the issue.
Also, I don't call Show on the form, but on the DockContent which is implemented in the Docking Suite, I don't know how it works there.
When closing I just hide the form, which as far as I know is how it worked in previous versions...

Ok I checked this further, the UserControl Load event seems to be called, obviously I can add a flag to protect this case, but this event should be called only once so I'm worried that the fact that this event is called again will have other negative effects.

My guess is that somehow the control is closed or moved to a closed state, causing another load when displayed. However, the inner controls instances seem to be the same, so they are not completely destroyed, maybe the window handle is recreated or maybe just the event is called, not sure.

EDIT: According to MSDN this event can be called again when it's an MDI child or when someone calls RecreateHandle. So I'm guessing it's probably a call to RecreateHandle. It would be best if you can verify this is the cause, meanwhile, I'll add a boolean in my code.

[keisari]

Anytime I try to change the properties of a room (like the edges or the scaling level of a walkable area or whatever), I get an error like this:

Code: AGS

Error: Object reference not set to an instance of an object.
Version: AGS 3.2.2.112

System.NullReferenceException: Object reference not set to an instance of an object.
   at AGS.Editor.RoomSettingsEditor.HandleKeyPress(Keys keyData)
   at AGS.Types.EditorContentPanel.KeyPressed(Keys keyData) in D:\Tools\AGS\ags\branches\dev\3.2.2\Editor\AGS.Types\EditorFeatures\EditorContentPanel.cs:line 48
   at AGS.Editor.TabbedDocumentManager.ProcessKeyDown(Keys key)
   at AGS.Editor.frmMain.frmMain_KeyDown(Object sender, KeyEventArgs e)
   at System.Windows.Forms.Control.OnKeyDown(KeyEventArgs e)
   at System.Windows.Forms.Control.ProcessKeyEventArgs(Message& m)
   at System.Windows.Forms.Form.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Form.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyPreview(Message& m)
   at System.Windows.Forms.Control.ProcessKeyMessage(Message& m)
   at System.Windows.Forms.Control.WmKeyChar(Message& m)
   at System.Windows.Forms.Control.WndProc(Message& m)
   at System.Windows.Forms.PropertyGridInternal.PropertyGridView.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.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

This is in a new game (any template), I don't have any other games to test on right now.

EDIT: BTW, the file path shown in the error message does not exist on my computer.

[tzachs]

New version in the first post with a fix to the crash described by doomantia.

Ok I checked this further, the UserControl Load event seems to be called, obviously I can add a flag to protect this case, but this event should be called only once so I'm worried that the fact that this event is called again will have other negative effects.

My guess is that somehow the control is closed or moved to a closed state, causing another load when displayed. However, the inner controls instances seem to be the same, so they are not completely destroyed, maybe the window handle is recreated or maybe just the event is called, not sure.

EDIT: According to MSDN this event can be called again when it's an MDI child or when someone calls RecreateHandle. So I'm guessing it's probably a call to RecreateHandle. It would be best if you can verify this is the cause, meanwhile, I'll add a boolean in my code.

Well, the stack trace shows it's coming from external code, so it's either the docking sute or dot net.
However, all docking panels are in fact MDI children, so that goes hand in hand with MSDN.

[SpeechCenter]

In my latest implementation I started to using IScriptEditorControl to display the current script. This works fine in 3.2.1
I tested the plugin with the 3.2.2 branch and it seems once you move the pane out, the script edit control loses all the syntax highlighting. I checked this and it appears that when the handle is recreated the Scintilla control gets WM_DESTROY which causes all the settings to be lost.

In the editor there's a hack that calls ReInitializeScriptEditor so essentially it just recreates all the data. In the plugin interface it's much more difficult since here is no option to re-initialize everything. I tried looking for a solution, but it would be much more hacky than the editor solution and hardly maintainable. So IScriptEditorControl is basically broken.

Finally, I tried to see if anyone handled this in ScintillaNet and my first search brought this https://scintillanet.codeplex.com/workitem/11811

So if I compare the code it seems AGS uses a very old version of ScintillaNet, probably before they fixed this bug. It's possible we won't need the hack in the editor if there is a newer implementation. Unfortunately we don't use the ScintillaNet dll, but rather embed their code in AGS.Controls and beyond that they seemed to change the interface so it's not backwards compatible.

If this is not solved in the editor the real solution in the plugin would be to ignore the editor interface and just use a new version of ScintillaNet directly, but I think it's better the editor would migrate to the latest version since it would solve more problems.

Incidentally, their accompanying app references the same docking window suite you used, so it probably means there's support for that.

[tzachs]

Nothing would please me more than removing those ugly hack(s) that were made in the script editor to workaround the WM_DESTROY issue.
However moving to the new scintilla version sounds like a lot of work.

Note that it's not just an old scintilla version embedded in the code, it's an old modified version.
I wouldn't be surprised if those modifications will no longer be needed with the new version, but it would have to be handled very delicately.

[SpeechCenter]

Yes, only it's not simple to compare the source to view what was changed in AGS since I'm not sure we know the version that was taken (and it's possible Scintilla skipped some tags).

Anyway, I agree with you it's not trivial, but on the other hand it's also quite isolated from most of the code.

If it seems not feasible by the time of the release we could consider adding to the interface an init function. it would mean a code change for anyone using the interface, but at least it would be relatively simple. Still, it's better if someone had the time to upgrade this component.

[dbuske]

Why was custom resolutions not included? 

[Crimson Wizard]

Why was custom resolutions not included? 

I explained why here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=47344.msg636447731#msg636447731

[Crimson Wizard]

I don't know if anyone tested this before, I installed the latest editor version to C:\Program Files, and I am getting this error every time on exit, because Editor tries to write Layout.xml:

Error: ОÃ'‚казано в доÃ'Ã'‚Ã'Æ'пе по пÃ'Æ'Ã'‚и "C:\Program Files (x86)\Adventure Game Studio 3.3.0-b\Layout.xml".
Version: AGS 3.3.0.1130

System.UnauthorizedAccessException: ОÃ'‚казано в доÃ'Ã'‚Ã'Æ'пе по пÃ'Æ'Ã'‚и "C:\Program Files (x86)\Adventure Game Studio 3.3.0-b\Layout.xml".
   ÃÂ² System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   ÃÂ² System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
   ÃÂ² System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
   ÃÂ² System.IO.FileStream..ctor(String path, FileMode mode)
   ÃÂ² WeifenLuo.WinFormsUI.Docking.DockPanel.Persistor.SaveAsXml(DockPanel dockPanel, String fileName, Encoding encoding)
   ÃÂ² WeifenLuo.WinFormsUI.Docking.DockPanel.SaveAsXml(String fileName)
   ÃÂ² AGS.Editor.WindowsLayoutManager.SaveLayout()
   ÃÂ² AGS.Editor.frmMain.frmMain_FormClosing(Object sender, FormClosingEventArgs e)
   ÃÂ² System.Windows.Forms.Form.OnFormClosing(FormClosingEventArgs e)
   ÃÂ² System.Windows.Forms.Form.RaiseFormClosingOnAppExit()
   ÃÂ² System.Windows.Forms.Application.ExitInternal()
   ÃÂ² System.Windows.Forms.Application.Exit(CancelEventArgs e)
   ÃÂ² System.Windows.Forms.Application.Exit()
   ÃÂ² AGS.Editor.GUIController.ShowWelcomeScreen()
   ÃÂ² AGS.Editor.frmMain.frmMain_Shown(Object sender, EventArgs e)
   ÃÂ² System.Windows.Forms.Form.OnShown(EventArgs e)
   ÃÂ² System.Windows.Forms.Form.CallShownEvent()
   ÃÂ² System.Windows.Forms.Control.InvokeMarshaledCallbackDo(ThreadMethodEntry tme)
   ÃÂ² System.Windows.Forms.Control.InvokeMarshaledCallbackHelper(Object obj)
   ÃÂ² System.Threading.ExecutionContext.runTryCode(Object userData)
   ÃÂ² System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
   ÃÂ² System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
   ÃÂ² System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   ÃÂ² System.Windows.Forms.Control.InvokeMarshaledCallback(ThreadMethodEntry tme)
   ÃÂ² System.Windows.Forms.Control.InvokeMarshaledCallbacks()

It only works well if I run it with administrative rights (or install on other disk).

The worse thing is that this error completely prevents user from closing application. I was able to do so only with the use of Task manager.

[tzachs]

Thanks, fixed this in Git.
Saving the layout file to the app data folder (as described by Microsoft's best practices) instead of the executable folder, so it should work now...

[Crimson Wizard]

Thanks, fixed this in Git.

Umm... have you pushed it to remote repository?

[SpeechCenter]

Have you also looked at the exception causing the editor to be unresponsive?
I'm asking because this is what I also had the same behavior when I saw the AGS.Native error, but since it happened in start time I assumed it was related. It may be a regression, not sure.

[tzachs]

@Crimson Wizard: Yes..
@SpeechCenter: What exception?

[SpeechCenter]

The worse thing is that this error completely prevents user from closing application. I was able to do so only with the use of Task manager.

I'm referring to this text, perhaps there's a need to also fix the error handling if another error/exceptions ever occur so at least the user can close the application properly.

[tzachs]

I haven't looked at it.. Just made a fix to the critical issue so that CW could release the beta.

[Crimson Wizard]

I haven't looked at it.. Just made a fix to the critical issue so that CW could release the beta.

Well, I did. Now its time to do patches .