I've been using WAMP server for a few of my school projects however I have had a lot of trouble with it staying green. I am pretty sure its an internal issue but I'm not really sure how to figure out what exactly is happening. The main problem I experience is that it installs fine and runs. However, whenever I restart my laptop it will not turn green. It stays orange and says 1 of 2 services running. I tried the methods I saw online however it does not even let me right-click it to see what isn't running or to restart the services. I've had to reinstall it about five times to keep using it and it's getting extremely annoying. I think it has to do with mySQL not starting properly but then why do I not get the option to right click?
check if you have any previous installations ( for example : mysql,MariaDB ..ect ) and open task manager and see the proccess of mysql ( open the properties ) if the path isn't from the wamp mysql then desactivate it / kill the process.
here's FAQ Link that helped me alot in the past , you may find it usefull
Related
Im trying very hard to like virtualbox, but so far I find it so much worse than vmplayer in so many ways. If it wouldnt take me hours to install everything back into vmplayer i would have moved back days ago
When I open my ubuntu vm my host OS's (windows 10) toolbar is still visible at the bottom of the screen, cutting off the actual virtualbox toolbar
Please help me
(edit) It is in fullscreen mode already, it just still shows the toolbar/taskbar from the host OS
Open Task Manager of Windows 10, Select "Windows Explorer" and Restart.
Reference Link
I had this same issue. The Windows 10 taskbar was still showing when I had VirtualBox in fullscreen mode, and what caused it for me was I had a program called Rufus (for creating bootable USBs) open and it was keeping the taskbar from hiding. Once I closed Rufus, everything worked as it should. So, maybe you had a program keeping focus on the taskbar, something that needed attention, and wouldn't let the taskbar hide.
I ran into the problem once. Not sure what had caused the that but I managed to find a solution by enabling "task bar" hiding option in host windows 10 machine.
Right Click on Task Bar -> Task Bar Setting -> Enable Task Bar hiding Option.
You are able to switch to fullscreen mode on the VM, this should hide the Host OS.
This image shows you where you can find the option:
If this is not what you are looking for, please elaborate on your problem, maybe add a screenshot showing the problem you are having.
I just experienced this exact problem, namely Windows 10 host taskbar would not go away despite the guest being in full screen. Even though this question is old, since this question got the top google page rank, I thought I would share how I fixed it.
I fixed it by shutting down Virtualbox and then rebooting the Windows 10 host. It is possible as others have pointed out that some app was keeping the taskbar active, but I couldn't find any such app. If it was some rogue app that was just running as a process (with no taskbar presence), the reboot nuked it from orbit and fixed the problem.
After installation virtualbox tools You can press
host + F (in my case Ctrl + F)
buttons to run fullscreen in virtualbox.
I moved five different sites into MAMP Pro 4.0.6 recently, and now the program is running very sluggishly. I get periodic spinning beach balls anytime I touch the interface, and Activity Monitor shows MAMP %CPU shooting up to 75 and even 100 + shortly after. Once I get a site actually open, it seems to run fine in the browser. It's just the MAMP interace has ground to a halt.
I thought this might be a port conflict, but moving away from 80/3306 to program defaults has not solved the problem.
I also thought this might have something to do with using PHP 7.0.12, so I moved back to 5.6.27, but this has had not impact either.
Can anyone suggest other ways to troubleshoot this? I've looked in my logs and have found nothing overly suspicious except for reference to a two.crt files left over from a dev server SSL install. I removed these, but I'm not sure if this would have any impact.
Thanks.
-- Lee
I have a remote desktop and i'm trying to run a simple script to prevent idle session timeout, which is 3 min (quite annoying). The script should, for example, press "A" key every 2.5 min or so.
Problem is, the remote desktop window is often inactive/minimized and:
1) if i try to run such a script "inside" the remote desktop, i still get disconnected, despite it actually works (continues to type or create/delete files etc even as the "idle timer expired" message is on screen). i believe the system wants some "external" action.
2) if i run the script on my PC, it doesn'do anything at all on the remote desktop (i had an open notebook there, and there was no typing):
ControlSend("[CLASS:TscShellContainerClass]", "", "[CLASS:OPContainerClass; INSTANCE:1]", "{A}")
I think the problem lies with the "controlid" part, which i got via autoit window info. If i set controlid as "" - it works, but only if the window is currently active.
I've seen a registry key solution, but doesn't seem to work for me.
If anyone has any ideas about fixing this, please, don't hold back:)
I know it's late but here's the ONLY thing I could get to work; it involved activating the window. I tried ControlFocus but to no avail, so here's what I got.
You should be able to modify your script as needed.
#include<Array.au3>
OPT("WinTitleMatchMode",2)
$a = WinList("Remote Desktop Connection")
;_ArrayDisplay($A)
ConsoleWrite(UBound($A)& #CRLF)
FOR $N = 1 to $A[0][0]
$hActiveWindow = WinGetHandle("")
WinActivate($a[$N][1]) ;comment if using controlfocus
;ControlFocus($a[$N][1],"","") ;comment if using winactivate
ControlSend($a[$N][1],"","","^+{ESC}")
WinActivate($hActiveWindow)
Next
Build time of XPages application containing several JARs, Java sources and ~50 XP/CC elements takes about minute to build on server via WAN. I have replicated application to local, build time dropped to ~10s.
Since few days ago build of local application is extremely slow, about 2-5 minutes. After some experiments there is workaround: to disable TCP port in location document - it drops build times to just few seconds. Even tho it works, it does not help much - testing requires user to be authenticated, so I need to replicate design changes to remote or local server - and that means to change location (online/offline) every time.
UPDATE 2013-04-04: I have duplicated my current location document and removed home and directory servers. To my surprise, with this location build times went back to few seconds - with TCP port enabled so replication is possible. Bigger surprise was the fact, that returning home/directory servers back to new location did not reproduce the problem - in fact they do not affect performance. I know it because I have renamed current location document and everything went to normal. From my understanding, "something" in client configuration was connected to location name. Thanks to Simon's tips I will investigate further.
The question is still open: I am looking for some (eclipse) preference controlling this behavior - unintended communication with server during build of local application.
Solution:
Teamstudio CIAO hooks into designer and checks for every update of design element. Seems to be lack of code optimization to me: it checks whether currently built design element (every single one, one by one) should be controlled in CIAO config database.
This explains why the problem was solved by renaming of location document. I was disappointed yesterday, when performance problems started again. Fortunately, I recalled CIAO setup to that location document about that time. CIAO uses teamstudio.ini file in DATA directory to configure what CIAO configuration database is used for every location document. Look for entry:
CIAOConfigDb[location name]=server name;CIAO\CIAOConfig.nsf
For development on local replicas with connection to server (for replication or local server), use location document with CIAO disabled.
This works only with property ForceConfigLocation=0.
Not a solution (yet!), but may help in the investigation. I'll update further if you post results later.
Debug instructions.
Add the following to the shortcut that launches the Designer client.
-RPARAMS -console -debug -separateSysLogFiles -consoleLog
Start the designer client. This will also open up the OSGi console.
Reproduce the issue. While it is still in progress in the OSGi console type the following:
dump threads
Do this three times, with a small amount of time between completion of each dump. Once done open the three heap dumps (in the IBM_TECHNICAL_SUPPORT folder) in the Heap Dump Analyser.
It will show you what threads are consistent through all three dumps. Take a look at those and look for package names/calls which may appear to be a functional area. Once you have that then you can try adding the debug for the related class.
For example: Let's say you notice "com.ibm.designer.domino.ui.commons." in the thread, then you would edit the rcpinstall.properties file. It will be in:
<Notes Install>\Data\workspace\.config\rcpinstall.properties
and you would add (start with FINE, then FINEST if nothing):
com.ibm.designer.domino.ui.commons.level=FINE
Now when you restart the designer client it will generate debug output in the workspace\logs folder for that package. You need to then go through the trace logs looking for the time when the delay occurred and see if it makes any references to related design elements.
Other open applications may get built at the same time (which looks like a bug top me). Be sure to close all other applications and the server based replica. Open applications have their icon showing in the application list and they stay open even if you close and reopen the Designer. In Designer 9 right click application and select "Close Application". In 8.5 you need to use Package Exprorer for closing.
Another good way is to use Working Sets. Only applications in open Working Set will be built (AFAIK). Have a Working Set with this one app only (and the app only in this Working Set).
update 1
If these don't help I would delete/rename bookmark.nsf, Cache.NDK and desktop8.ndk. Then open just this one app and see what happens.
update 2
Check that there are no referenced projects. Right click the application and select "Project Properties". From there "Project Referencies" and make sure no check boxes are checked.
update 3
Based on your update I would check the item names starting with $ in location document. Sometimes there are saved IP addresses etc. which could cause this problem. All those items can be removed.
If possible (and if You are not using it yet) try to use version 9 of the Domino designer (You do not have to use Domino 9 to do that - it works fine with Domino 8.5.3).
For our projects build times went down to only few seconds from few minutes. I guess that they finally noticed at IBM that the build process used to heavily relay on connection to server and done something with it.
With new designer You don't event have to replicate to local. You can directly work on Your local server.
I have been working with marmalade for some weeks. But since today my simulator is not working anymore. I always get "error: Couldn't initialize Direct Draw" when i launch the simulator.
I tried uninstalling marmalade and restarting pc but nothing is helping.
Anyone has an idea what this can be, or things I can try?
Error message can be seen:
PC specs if this might help:
- Acer Aspire notebook
- Windows 7 Home Premium SP1 64bit
- Intel i5 2410M
- 6GB RAM
- AMD HD 6650M 1GB
For anyone who may come across this, the same thing happened to me just yesterday. I started getting the "Couldn't initialize Direct Draw" on startup after having made a few changes under Preferences -> Display.
I fixed it by going to C:\Users\{user}\AppData\Roaming\Marmalade\ and deleting (or renaming) the preferences.icf file. This isn't removed after an uninstall, so if you find yourself in this situation, this seems to be the only way to reset everything.
Good luck!
A couple of things to try.
First, try running your program from inside Visual C++ by pressing and holding F5. This will cause the simulator to start but won't start executing your program, which might then give you a chance to change the settings in the simulator.
Failing that, if you look in the data directory you should find a file called development.icf which is the current simulator settings. Try deleting this and running again which will cause the simulator to revert to its default settings.