This morning I finally made my mind and decided to ask you for help. Problem is that in my Delphi application no hints are shown at all...
I have read about THintAction problem, I have read guides/tutorials/manuals, tried to invoke Hint windows ( firing event handlers ) manually, but nothing worked. They just doesnt show.
I have run out of ideas ...
I have tried to: setting parent showhints on components, forms, from event handlers, application activatehint() ...
Is there any other way to do this ( except API calls, of course )?
First, what version of Delphi do you use?
Second, I recommend you try creating a simple application from scratch, with just one form and say a tool-button (or any other control that can show hints), with ShowHints activated, and see if it shows. If on such a very simple app you'll get no hints, I would recommend reinstalling Delphi, maybe something in your installation is screwed up...
I bet you're on XP and your installation is rather old.
A friend of mine had this exact problem in his machine. No VCL hints were showing up in his machine. That includes the apps he built, the Delphi IDE he used (7 afaicr) and any other Delphi built app he had on his machine. So we had concluded by blaming his WinXP instance which has been on the run for the last 2 years with a lot of garbage in it (most likely it was some app he installed sometime that was hooking messages at some point causing this weird behaviour). It might be your case as well.
ps. Another interesting point - the hints were showing up if you set Application.HintPause to a low value like 100-200. You may want to try that as well.
Have you tried adding Application.ShowHint to your project file?
The project file would then look something like this
begin
Application.Initialize;
Application.ShowHint := True;
Application.CreateForm(TfrmMain, frmMain);
Application.Run;
end.
I've just had this problem on Delphi-5, "run-time application won't display hints on mouse-hover".
It works fine on my other applications.
I've traced it to the following:
Project|Options|Compiler|Debugging|Use Debug DCUs
This was checked, unchecking and re-compiling enables my hints.
A few tips:
Check if you or another component/unit has set a custom hint class. If so, find that component/unit and remove it.
Compile your application with Debug DCUs and put breakpoints at the appropriate places in Forms.pas. Then single-step through the code and see what happens.
Okay - As I Recently Upgraded to 2010 version ( 14.x ), I finally was sure that this Hint problem is Bug in the IDE.
Only solutions is:
- change the HintPause property
- try to reinstall IDE
I also encounter my PC( win10 ) can't show my ap's (made by Delphi 7) hint.
work again after I put following line in .dpr file :
100 is magic number, 500 or 1000 not working.
begin
Application.Initialize;
Application.ShowHint := True;
Application.HintPause:=100;
Application.Run;
end.
Related
Not a programming problem per se, but rather a programming environment problem that I have been unable to find a solution to.
The problem relates to Adobe's Extendscript Toolkit (both 3.5 and 4), but so far I haven't been able to solve the problem, so here I am...
The error I get has appeared more or less over night. I didn't experience this problem yesterday, nor this morning. But exactly WHAT has happened is beyond me. I have removed preferences, I have uninstalled, reinstalled, created a new user, restored old preferences from Time Machine and I'm now pretty much lost for options.
Basically, nothing works in ESTK anymore. Just opening ESTK and entering alert('Hello') won't work. Neither will $.writeln(). Everything running from within ESTK seems to give the same error;
Cannot execute script in target engine 'main'
With details:
Cannot execute script in target engine 'main'!
(#1116) Can't start debug session.
Below is a screenshot taken from the new user I created to test, same problem.
The "funny" thing is that all the scripts (InDesign CS5, still hanging on to it for reasons) still work perfectly in the applications' script panels. So there is nothing wrong with the scripts (heck, they haven't changed one bit, and still refuses to run in ESTK).
As mentioned, I've tried installing the ESTK CC (version 4) as well, but the very same problem occurs there. Which leads me to think the problem lies somewhere else, but I do not know where, and why.
So, if anyone can shed any light on this issue, at all, I would be very happy. Debugging is basically the only thing ESTK is good for in my book, but now that even that functionality is gone, I don't know how to efficiently debug the scripts which is kind of hampering the workflow.
For reference, I'm running InDesign CS5 (from the old Creative Suite) on a 2008 Mac Pro with 10.11.6 (El Capitan) installed. Well aware that it's pretty out of date, but that is beside the point here.
In the above mentioned forum, Adobe has published a stable workaround!You just have to correct a setting inside the estk application:
Open the file(Mac): “/Applications/Adobe ExtendScript Toolkit CC/ExtendScript Toolkit.app/Contents/SharedSupport/Required/cdic/11BTBackend.jsx”
Search for the value: 604800000 (line reads bt.timeout = 604800000)
Replace that value with 604800 and save
Quit ExtendScript Toolkit and relaunch.
I can confirm that it works.
From the adobe Forum :
"we have found a first workaround: just change your date to any date before 20-nov-2018"
https://forums.adobe.com/message/10761440#10761440
Seems like a date issue :(
I just published a quick update about this on the Adobe Tech Blog.
For the time being, if you dismiss the dialog, you can still run your script via ESTK and step through code as usual.
Alternatively, if you really want to avoid the dialogs, and you don’t mind setting your clock back, you can sidestep the issue by setting your system clock back to November 19, 2018 or before. On most systems, changing the system time can have unintended side effects, so this isn’t recommended unless you’re really certain about it.
I have inherited a program written in VB 6 that is not working when the user tries to print. I had some ocx files I needed to register (regsvr32), which I found using Process Monitor, but I can't see where this error is coming from. Is it possible to find out what component the program was trying to create? This program was written by someone else and I don't have access to anything but the original setup program. Thanks.
So the issue was not the old program, but something to do with Access. I happened upon some articles dealing with this particular issue, but nothing worked. I had to install Access 2013 32 bit in order to make this work. I didn't really fix the cause of the problem, but I wanted to put this here to point any future sufferers they check Office and their program if they run into a similar issue.
HTH
Wade
I have the following bug in a program:
An MDI MFC program closes silently on Windows 7 (terminates the process without prompting to save changes and without displaying any "crash" dialog) when the user performs this operation : Click a context menu item.
But this happens only on that PC, at least, for the moment. No other PC has encountered that problem. However the bug can always be reproduced following the same steps but only on that PC.
I want to know the reason but probably the customer won't allow me to install many programs to debug, so I need to be able to log when the program terminates, or print the stack in Release version but I'm quite lost.
I had faced a similar bug before and eventually I fixed it logging line by line and changing the problematic part, but I guess there are much better ways to find bug reasons than this.
I have tried on my development PC to create minidumps on Release mode but if there is no exception thrown on that PC, (I haven't confirmed that yet, though...) maybe it's pointless.
Also used an available class on codeproject (Stackwalker) but I don't manage to print all the function calls. Only on simple console programs, but not on MDI or even SDI.
Any ideas on how to find out the reason? Thanks in advance.
I have a VB6 application that I provide support for. This application works on both Windows XP and Windows 7. Some users were migrated from Windows XP to Windows 7 using the User State Migration tool. These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application. My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed. The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming. At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful. All of the non-successful calls match between working and non-working.
Installed the Windows Debugger Tools and captured a crash dump. Analyzed the crash dump with DebugDiag. DebugDiag says the exception is in msvbvm60.dll. I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it. This same PDB file works fine when I do remote debugging, however.)
I recompiled my VB6 program without any optimizations in PCode. I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.
Used the above created PDB file to remote debug the VB6 application. The debugger says that the application crashes after the new window has been created, on a line that sets MousePointer = vbHourGlass... To me it seems unlikely that this is the real cause of the error. There are at least 20 other locations in the program where this same line is called and all work fine.
(Forgot about this one)
Used Dependency Walker and profiled the application on both a working and non-working computer. All errors found by dependency walker were the same between the two computers. There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.
None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)... There are no entries in the Windows Event Log related to the app crash.
The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#MarkHall I have tried running it as admin, though not with UAC off. The application runs fine on a Windows 7 box as a non-admin with full UAC. Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.
#Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
I'm trying to debug and resolve some issues with a Win32 macro application written C++ however I'm having the strangest issue.
I have to launch a 16-bit program and then simulate entering data into and have been using ShellExecute for over two years now. I haven't touched this actual code at all, but now it doesn't work.
I'm doing ShellExecute(NULL, "open", exe_path.c_str(), NULL, "", SW_SHOWDEFAULT);. This has worked flawlessly for years but all of sudden, it stopped working. It gives me an ACCESS_DENIED error code. I've Googled and apparently this is a pretty common issue with launching 16-bit apps.
The workstation XP SP2 environment hasn't changed at all, and it was actually working until I rebuilt a little while ago (I've rebuilt it before many times).
The code is inside a window procedure function and when I take it out and launch the program in the WinMain function it works, but the code has to be in the window procedure...
I've tried numerous alternatives but they all give the same issue.
The biggest issue with this is it was working then all of a sudden decided it wasn't going to with no change to both code and environment! In fact, it was about half way through testing changes that it thought it'd stop working.
Please help as I cannot do anything without the program launching. It's the first step in the code that I'm debugging!
I've discovered the issue. I changed the lpDirectory parameter (of which I was supplying NULL or "") to the directory of the executable, using the PathRemoveFileSpec() function.
The application is launching again. Now I can continue fixing the rest of the program!