I've Followed a tutorial on getting ironruby up and running and that works great. However when I try to delve a little deeper, like using button click events I get this error;
Could not load type 'System.Reflection.Emit.ModuleBuilder' from assembly 'mscorlib, Version=3.7.0.0, Culture=neutral, PublicKeyToken=969DB8053D3322AC'.
And my MainPage.rb
include System
include System::Windows
include System::Windows::Controls
# Set the titles
Phone.find_name("ApplicationTitle").text = "this is the application title"
Phone.find_name("PageTitle").text = "and page title here"
# Create a new button and add to page
button = Button.new
button.content = "Click Me"
Phone.find_name("ContentPanel").children.add(button)
button.click do |s,e| # breaks here
MessageBox.show("Button Click Works!")
end
Is it currently posisible to build professional apps with ironruby?
The issue with using dynamic languages on Windows Phone 7 is it's omission of the System.Reflection.Emit implementation. However, IronRuby is able to run most code through it's interpreter, rather than emitting IL, which makes it possible to run in Windows Phone 7. However, things like subclassing CLR types and implementing interfaces require emitting IL, so those .NET interop features will not be functional on Windows Phone 7.
For your specific example, instead of using a block, try using a method:
def on_button_click(s, e)
MessageBox.show("Button Click Works!")
end
button.click.add(method(:on_button_click))
However, if this is not working for you, please submit an issue.
Probably BUT I personally think the only way to do a professional job is using the native OS. That way you have the most power of what you have to do
Related
I get following message when I try to add "Periodic Task" to "ScheduledActionService" in Windows Phone 8 Application.
"The drive cannot locate a specific area or track on the disk."
I am really not sure if this is related to Visual Studio 2012 that I am using or related to Periodic Tasks on Windows Phone 8.
The same piece of code works fine in Windows Phone 7.
I found the solution here: http://social.msdn.microsoft.com/forums/en-us/wpdevelop/thread/a973955e-0981-4be8-8ac0-8dfcb9dc2917/
You need to manually update your WPAppManifest.xml file and configure the background task there.
Appears to be normal behavior, not related to emulator or debugging.
There is a excellent explanation as to what is required by microsoft for background task in the msdn tutorial videos.
It references your problem at around 24:30 with editing the WPAppManifest.xml file.
He explains step by step what needs to be done and why.
http://channel9.msdn.com/Series/Windows-Phone-8-Development-for-Absolute-Beginners/Part-34-Creating-a-Background-Agent-for-Scheduled-Tasks
Also I got a null reference exception after fixing the WPAppManifest.xml when called from the the main project, turns out the main project also has to reference the scheduler project (even if not using anything in it).
You have to add the ScheduledTaskAgent as a Reference to the main project.
I found this in the WPDT Notes
Runtime exception occurs when an application attempts to use a launcher/chooser in Microsoft.Phone.Tasks to call an application that is not present in the Emulator home screen. The following error string is displayed, “The drive cannot locate a specific area or track on the disk.” Workaround: Do not use the launcher/chooser or catch this exception.
http://download.microsoft.com/download/d/9/2/d926fb38-bb43-4d87-ae5a-1a3391279fac/releasenotes.htm.
(PS If you can't view the link Google "Windows Phone Developer Tools CTP Release Notes")
I keep reading tutorials of how to use it in Silverlight Apps, but I need it in XNA. All tutorials refer to the package Microsoft.Xna.Framework.GamerServices, but there is no such class...
What am I getting wrong?
You're probably not going to want to show the message box class via XNA unless you truly are displaying some type of system type message.
If you're just planning on communicating something via your game to your player, then you'll want to roll your own so you can theme it appropriately to match your game.
Otherwise, the above answer about using GamerServices is correct, that's how you display a MessageBox via XNA but again, you should really restrict your usage of that class for purely system type messages (e.g. "You must be signed in to purchase this game.")
First, check that you have a reference to the Microsoft.Xna.Framework.GamerServices assembly (in the 'Solution explorer' window, expand 'References'). If you don't, add it (right click on 'References', and click 'Add reference'). Then, you can use Microsoft.Xna.Framework.GamerServices.Guide.BeginShowMessageBox to display a message box.
If you can't get the other suggestions to work for you, I recommend checking out the Game State Management sample. It has its own message type popup windows. But more than that, it is a great starting point for any XNA game.
http://create.msdn.com/en-US/education/catalog/sample/game_state_management
Working on writing a custom property Handler for our custom file type in windows 7. I have installed the Windows 7 SDK and built the sample Property Handler. After registering the handler, it works great in Windows Explorer, but in the common file open dialog the custom values do not appear. Does anyone know if there is something special I need to do to get the properties to appear in common dialogs?
Explorer:
File Open Dialog:
OK, figured it out. Here is the deal. My app is 32 bit and I am on a x64 system. Because the PropertyHandler is written in x64 to support the shell out of process. But for the file open dialog it needs to run inprocess, so the x64 dll can not run. I confirmed this by creating a quick x64 app and the fileopen dialog works the same as the OS. Hope this helps someone else in my shoes later on, hate answering my own question, but don't want people wasting NRG on this one as I found the solution.
I have a VB6 application, the installer is compiled using INNO Setup.
The installer runs fine. But in about 10% of computers when the user clicks the Icon to run the installed app, it doesn't start, no error message, only a Beep sound.
This is happening on XP and also Win 7.
I develop in XP and Win 7 and the application works OK, so I haven't been able to reproduce the issue.
The installer registers all ocx and dlls needed (afaik). (Well not completely all, it assumes MS run-time components should be there, but I guess an error message should show up if something is missing)
I was thinking some kind of user permissions, UAC, but even users in the admin group have had the issue.
Could you point me to what possible issues to look for and test in order to patch the app.
Thanks!
[FOLLOW UP]
Thanks to the tips, found out the manifest is causing the problem. I use it to make the controls look better:
http://www.vbaccelerator.com/home/vb/code/libraries/xp_visual_styles/using_xp_visual_styles_in_vb/article.asp
Now I'm trying to discover why. I have another application with the same manifest and that one works ok.
Haven't been able to get feedback on the event viewer yet.
The "beep crash" often points to an error in an application manifest such as an XML syntax error or namspace conflict. Event Logs will often provide a hint about this.
But I've found that people often try to use the Common Controls 6.0 Library without ensuring proper library loading sequence.
Before any Forms are openend you should load shell32 and then comctl32. The easiest way is a couple of no-op calls in Sub Main:
Option Explicit
Private Declare Sub InitCommonControls Lib "comctl32" ()
Private Declare Function IsUserAnAdmin Lib "shell32" () As Long
Private Sub InitCommonControlsVB()
IsUserAnAdmin
InitCommonControls
End Sub
Private Sub Main()
InitCommonControlsVB
Form1.Show
End Sub
Without this your program will usually work fine in Vista or Win7, but will fail on some XP service pack and patch levels. Part of this is due to changes over time in the Fusion subsystem that handles SxS activation and comctl32.dll patches.
Ignore those saying you need to call InitCommonControlsEx(), it isn't necessary unless you are constructing and using Win32 controls directly instead of VB6 and COM controls.
A few things to try to narrow it down:
Check the Windows Event Log for crash events
Check the Windows Event Log (in the Application section) for crash reports from your application. You can quickly get to the log viewer on Windows XP by clicking Start > Run, typing eventvwr and pressing Enter. On Windows 7, you can type "event viewer" in the search box that is in the Start menu. You can filter the events to only show error events from your program.
You might find a few error events on one of the computers where this problem has already occured, because it sounds like the error reporting feature is turned off on these computers (in which case "hard crashes" like access violations are logged in the Event Log instead of displaying an error dialog to the end-user, as long as a debugger isn't installed on the computer).
Make sure "Error Reporting" is turned at the OS level
As mentioned in the previous section, it sounds like the error reporting feature is turned off on these computers. In that case, a crash won't display any kind of message to the end-user at all and the application will just vanish suddenly. In Windows XP, you can check this setting (and turn it on) as follows:
Right-click "My Computer" and select Properties.
Open the Advanced tab and click the Error Reporting button.
Select the Enable Error Reporting option.
Click OK to all the open windows.
Add trace code to your application
You could also add some trace code to your application's start-up code, such as code to display a message box or write a message to the Windows Event Log or to a log file as soon as your application starts (for example, in the Form_Initialize event of your main form, or in a Sub Main routine).
This way you will be able to tell whether your application is crashing before or after the VB6 runtime is loaded: if you try to start the application and it disappears/crashes, and your startup message isn't logged, then you know it's crashing before it even has a chance to get to your application's startup code, which could indicate that a dependency of the VB6 runtime or the VB6 runtime itself is not installed properly.
Note that Windows XP and Windows 7 both ship with the VB6 runtime pre-installed, but it's possible for misbehaving installers to overwrite or remove files that are part of the VB6 runtime.
Using C++/CLI, How to display a managed control (eg. System::Windows::Forms::Panel^) on a window created in native code?
An external program calls my native method where i can access it's window via
SubclassWindow(hNativeWindow, MyNativeWindowProc);
Then I create control with something similar to:
MyNameSpace::MyControl^ ctrl = osozKomunikator = gcnew MyControl("SomeText", hNativeWindow);
ctrl->Show();
MyControl is derived from System::Windows::Forms::UserControl and has overriden CreateParams to set Parent to hNativeWindow.
As the result the control flashes and dissapears, does not show at all or shows only after I slow down the execution with the debugger.
Please help.
Windows Forms supports being hosted like ActiveX in native windows since .Net 1.1. The host needs to implement some interfaces, though. MFC 8.0 wrapped around the necessary code in CWinFormsDialog and CWinFormsView. Use MFC's support classes if you can. If you can not, install MFC from Visual C++ 2005 or higher and check the source code of MFC's OLE support classes, like COleControlContainer, COleControlSite, etc.