Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 8 years ago.
Improve this question
I'm writing a front end application in MS Access 2010 saved as a standard accdb which users will only be able to use Access runtime to open. Our IT department has kindly installed the 2013 runtime rather than the 2010 runtime on a test machine for me to check my development on.
I'm having some issues getting anything to show in Runtime on this machine, yet when I use the /runtime switch in a shortcut on MY machine, everything works as expected. What is happening on the test machine is a dialogue warning of "A potential security concern has been identified" comes up with OK and Cancel. If I click on OK, the database opens as far as I can tell, and code that's in the form_open event of the startup form runs (checks to see the location of the file isn't a network drive to ensure that users copy the front end to their desktop) and a version control query to match the client with the latest version of backend. However the form never appears, and I get no errors/crashes or other unexpected events.
What could I have done wrong, or is it connected with the security warning? My gut says that's a red herring as the location check and version checking code does run, ie if I run it from the network drive then it gives the msgbox it was meant to.
Many thanks, this is my first time using runtime.
After several days of searching, I've finally solved the problem.
I had been developing on a laptop with a second screen connected. For some inane reason, Access remembered this, and decided to display the form on the second screen. Unfortunately, my users don't have a 2nd screen.......
Selecting Auto Center=Yes in the form properties solved the problem entirely.
Related
One of my duties at my job is to enhance and maintain a mature VB.Net windows application used internally by my company. We run 8 computers at the small company that each runs the app with no problems.
Recently we replaced one of the computers with a pretty standard notebook running Win 7 Professional with SP1 and for some reason, it won't display message boxes displayed using the normal MessageBox.Show("Message") method.
The vendor who sold us the computer says it must be the program, and I kind of sympathize with that view, but the fact is we have 8 other computers that all display their message boxes just fine.
Thought I'd post the issue here to see if anyone else has run into this and, if so, did they find a resolution?
I'm going to paint outside the lines a little bit and answer my own question with sort of a non-answer.
We battled that computer for about a week and a half and finally gave up and reinstalled the OS. Problem solved. Not really an answer because we still don't know what was going on or why reinstalling the OS fixed it.
Reinstalling was really an act of frustration/desperation as much as anything else. In the end we were just thankful the problem went away and we could move on. Figured I'd get this off of the unanswered questions list since I'm not really waiting for or expecting an answer at this point.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm developing a program in Visual Studio right now, but I want to be able to make a button that forces a blue screen on a windows machine. I know that there is a way to force one by make a CrashOnCtrlScroll key in regedit. But the requires a restart and for the application to be run again. I just want it to be instant or close to. Thanks :D
The blue screen appears only for kernel-mode errors. Code that runs in user-mode (such as a Visual Basic application) is not going to generate a blue screen. It can never directly generate a system crash.
The only way to do this is to install a kernel-mode driver that can force the blue screen, which you then invoke indirectly from your user-mode code. You mentioned one way: configuring the keyboard driver to initiate a system crash under certain conditions. Another option is to create a kernel-mode driver of your own that calls the KeBugCheckEx function (or equivalent), and then invoke this functionality from your VB application. For example, Mark Russinovich has written a little utility, NotMyFault (download here), that uses a helper kernel mode driver to force a crash condition.
A final option is to destabilize the operating system. I believe a simple way to do this is by forcibly killing the process "csrss.exe". Last time I checked, this caused a BSOD. Obviously this requires administrative privileges. And I'm not sure if there are checks in place within the OS itself now that prevent this process from being killed; it is very likely. And if you are allowed to destroy the state of the machine permanently, you have a number of fun options: for example, trashing the HKLM key in the system registry.
That said, dare I inquire as to the utility of such a "feature"? Would you and/or your users be content just installing the Blue Screen of Death Screen Saver?
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
The company I work for primarily runs Windows XP machine. These machines are getting old and need to be replaced. I wanted to wait until Windows 8 was released since it is right around the corner. So, I have downloaded Windows 8 to test run and figure out the problems I am going to have with my users, programs, goup policy, and etc.
After installing I noticed pretty much everything has changed and I was a bit lost for awhile. In my opinion the Metro interface sucks and is definitely going to frustrate my users. If they are not comfortable using it they are going to be bugging me frequently. Not to mention it is going to cause numerous amendments to our group policy.
Overall I think it could be time consuming to support. So, I was wondering if there was a way to disable the Metro interface and show a traditional start button on the desktop. I would like to do this without a hack if at all possible.
There is not a way to disable Metro and replace the Start screen with a Start button. The Start screen will be the way you select programs from now on.
You can still run apps with the traditional desktop and taskbar. You can get to the desktop by clicking the Desktop tile on the Start screen, or using the Windows Key + D on the keyboard. There is no start button the new Win8 taskbar, and clicking the Windows Key on the keyboard will bring up the Start screen.
edit: Windows 8.1 has since added back the good-old "Start" button to the taskbar.
If your users are primarily going to use email and the a web browser for their applications then the Metro UI, while requiring a learning curve, may be a better experience for your users anyway. If your users could benefit from a more mobile, touch-driven experience then Metro again might be better. If you have a lot of power-users that require tools such as Visual Studio or Photoshop, then they are going to spend a lot of time in the traditional desktop as those apps don't make sense with a Metro UI.
Although I haven't been able to get around seeing the (Metro) start screen before I can get to the desktop, I would really recommend you have a look at ClassicShell. It is an OpenSource project that gives you a start menu and a start button. Again, after logging in you will still get to see the start screen and there appears to be no way to get rid of this as was possible in the beta version with the RPEnabled REG_DWORD value.
Furthermore you can get rid of the lock screen (before the login prompt) by means of a policy change. Start gpedit.msc elevated, then go to Computer Configuration -> Administrative Templates -> Control Panel -> Personalization and in the left pane double-click the setting Do not display the lock screen and set it to Enabled.
Short of the above I would go with Kate's advice of sticking with Windows 7. Too many desktop users have voiced their discontent with the usability (or rather its lack) in Windows 8, so there is a slim chance Microsoft will have to take action and re-enable some traditional elements. Of course I wouldn't get my hopes too high ...
you can try using Metrocontroller (google for it), it disables some or all metro features supposedly
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a Cocoa app targeting Leopard and above, and I'm thinking about adding a crash reporter to it (I'd like to think my app won't crash, but let's get real here). I have some mostly conceptual questions before I really get started.
1) How does this work conceptually, knowing when there's a crash and bringing up a reporter? Do I have a daemon running looking for a crash, or do I wait until my app is launched next time to report?
2) Can this be done in Cocoa? Or would I have to dip into Carbon or IOKit or somesuch?
3) Is this even a good idea? Mac OS X already has a built in crash reporter, but as a developer I don't get to see the crash logs. I don't think my app will be crashing often, frankly, but I just don't want to be naive but this sort of thing.
What are your thoughts and opinions regarding this?
I've had a lot of success with UKCrashReporter. The code is straighforward and easy to modify to match the L&F of your app.
PLCrashReporter looks interesting, though.
I'd stay away from Smart Crash Reporter just because many users (rightfully) don't appreciate your app injecting code into unexpected places and it strikes me as a fragile (perhaps dangerous to use in a released app) approach.
Others have answered the question well and pointed to some good example code.
Coding it yourself is fairly simple. The strategy generally is:
catch appropriate signals
launch a separate crash reporter app that lives inside your application's bundle
the crash reporter app then finds the latest crash log entry for your app and sends it to you via whatever method you desire (POST, email, etc)
I've also rolled my own: SFBCrashReporter
There is a small post on my blog about it.
I have seen a few apps use Smart Crash Reporter or perhaps some variant of it. When your application crashes, it will bring up the usual Apple crash dialog with an extra button which says "Send to both Apple and You"
I would shy away from Smart Crash Reporter for the single reason that it has a bad taste for a lot of users, and is a good way to get bad press for your app (deserved or not) PLCrashReporter or UKCrashReporter http://zathras.de/angelweb/sourcecode.htm they will give some ideas about what to do and how to do it in ways that don't inject into other code space.
Another option is Google's Breakpad. It has a Cocoa framework wrapper, and is compatible with Mozilla's Socorro server. It's used by Firefox, and the Cocoa framework is used in the current betas of Camino. The client-side integration is pretty easy, but I've never looked at what it takes to run an instance of the Socorro server.
I'm using ILCrashReporter and it works really nicely. The method is email based so it works well with Fogbugz.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I know this isn't strictly a programming question but y'all must have experienced this.
So...you have four or five RDP sessions open over the corp VPN, you're bashing away inside your favourite IDE, your VPN to the data centre bounces briefly then recovers, all your RDP sessions start re-establishing their connections and whilst doing so sequentially keep grabbing focus, one after the other. Pretty bloody annoying and downright rude.
Any idea how to prevent this behaviour and just make the RDP client flash it's taskbar button instead of totally grabbing focus away from whatever you were doing?
#Jason - thanks for the reply, I'm running 64 bit Vista and 64 Bit Windows 2008. Any ideas how well it plays?
#Jason - good idea. Done.
#Ryan - thanks also for the answer. I tried Terminals a few times before, but quite often I need to see two or three sessions side by side which the tabbing doesn't really facilitate too well, would've been nice to have a 'pop out in own window' button. I did once grab the source code to fix stuff like that, but never got the time. I also found it behaved oddly whenever there was a brief network disconnect (e.g. xDSL flapping) and it would reconnect to the wrong session (usually a new one) and leave the session I had opened in a disconnected state on the server. Otherwise Terminals would've been really cool, we have 200+ windows servers, and organising all those .rdp files can be a pain.
I use Tweak UI to configure explorer so that apps don't steal focus; you can also configure how many times they flash in the taskbar as well.
EDIT: Once you are within Tweak UI, these options are found under General > Focus.
EDIT: #Kev, apparently there is a 64-bit version (not MS approved, apparently, I would scan it for viruses of course) that works successfully with the 64-bit version of XP. From what I understand, you download that and then run it in XP compatibility mode as administrator and it will do the trick. Tweak UI is basically a nice wrapper around a collection of registry hacks, so I imagine you could find the hacks themselves if you didn't care for running Tweak UI in this manner. Hope that works for you!
As an alternative, you could try using something like Terminals. It allows you to have multiple remote desktop windows open at once all as tabs in the same window. Quite cool. Also, it is open source so you can change its behavior if needed (although I don't believe it steals focus like a normal RDP session does).
Since I don't think there's an approved version of TweakUI other than for XP. Apparently making this change in the registry has a similar impact for Vista:
[HKEY_CURRENT_USER\ControlPanel\Desktop]
ForegroundLockTimeout = 0
However I found (Vista x64) that while focus on the original was maintained the offending window would still take the foreground - quite distracting.