In the article at How do I set the default install path with a windows installer? the directions state to 'select the Setup project in Solution Explorer, and examine the properties grid to find them', where 'them' refers to [ProgramFilesFolder][Manufaturer][ProductName]. Doing this brings up a property pages dialog that has configuration properties but nowhere are there fields for setting these, [ProgramFilesFolder][Manufaturer][ProductName]. I tried attaching a screen shot but was unable. The project is written in C#, .Net 3.5 using VS2010.
You're on the wrong properties dialog. Try the results of this thread.
Setting the manufacturer in a VS 2008 Setup Project
If you still have issues, post the screenshot.
Related
I'm working with Progress-4GL, release 11.6, appBuilder and procedure editor.
While working with OCX components, a WRX-file gets automatically created by the appBuilder. I would like to see the content of that WRX-file.
Currently, I've found this website, which also mentions that Progress IDE should contain such a viewer, but even after checking all Pro*tools, I didn't find any tool.
Does anybody know which tool of the Progress-4GL appBuilder/procedure editor toolchain allows viewing WRX-files?
Thanks in advance
According to Progress Knowledgebase, WRX files contain only design and runtime license keys (if required by the ActiveX Controls) along with any custom property settings that were made to any ActiveX Control in the windows. WRX files do not contain any ABL source or .r code.
If it indeed is an OCX you want to look into you can use the Com Object Viewer.
It can be found a couple of different ways.
Quick Access Search in Developer Studio:
Via Pro*Tools under the Tools menu in the AppBuilder
Once started you can use it to open OCXes and Automation Objects to look at the internal API's of those.
You need to locate the file it's stored in. This could be either by knowledge of it's location or other way. If you add an OCX to a ABL Windows/Dialog program you will see the location of the control there:
Then you can open it in the Com Object Viewer to see methods, events and such and also get some short coding help.
I want to disable the dialog (shown below, titled "Processing File") appears each time I compile or build my project, but I failed to find which IDE plugins it's from since I use a lot of productivity plugins (also shown below).
Anybody has any hint :P
The List of IDE plugins I use is shown below - PS, I believe the DKLang is not shown there.
As hinted by Andy Vines the Delphi G+ group user, that's because I somehow have enabled the 'Set Component Properties' expert included in the GExperts IDE plugin.
It searches for and auto-close active database connections, datasets, etc.
Disabling it fixed the problem. Thanks.
While I was using D2007 I've really got used to Project > Project Page Options feature to keep and view some free-form project notes, external references (these almost never being comfortably viewable in built-in HTML designer) etc. Now I have Delphi XE and Project Page Options is missing from Project menu, moreover, projpageide150.bpl mentioned in the documentation is not present in bin directory. How do i fix it? I'm really finding ability to view (not edit!) HTML documents in the IDE a very convenient feature.
It looks like it was dropped but has been re-instated. In my XE2 installation the projpageide160.bpl file is there, as is the Project | Project Page options menu. Neither are present in my D2010 installation.
I'm having a really strange problem with the Delphi 6 IDE running on Windows 7 (64-bit edition). I just can't find the Code Explorer window pane. Usually it's docked against the left side of the Code Editor window. If not there, then you can find it by opening the View menu and selecting Code Explorer. But the Code Explorer is not docked to the Code Editor and when I drop down the View Menu the Code Explorer option is simply not there. All the other options are: Project Manager, Object Inspector, Object TreeView, etc. but just not the Code Explorer. Everything else about the IDE works great. Has anybody else had this problem and if so, what can I do to get it back? I rely on that view quite heavily.
Also, once I undock a view it doesn't seem to want to dock again. I hover over the usual areas in the edit window and it won't accept it the orphaned view as a docking client.
-- roschler
I can't reproduce the missing Code Explorer menu item. It works fine for me.
Regarding the non-dockable windows have you tried right clicking on the troublesome floating window and making sure that Dockable is ticked?
One thing to try when Delphi's IDE is giving you grief is to delete any .dsk files.
Finally, Delphi 6 pre-dates UAC and assumes that you can write to the installation directory. Have you made sure that Delphi is able to do this one way or another?
Sorry I don't have a definitive answer, but this is all I can think of.
For the record,
I had the same problem as you Robert.
Configuration:
Delphi 6 Enterprise, installed to a custom location.
Update Pack 2
Several Third Party Components
Windows 7, Spanish and English languages in Regional and language settings, and keyboard layout settings. Default language 'spanish',
default keyboard distribution 'english'.
Issues:
No 'code explorer' context menu item,
In editor, no 'complete class at cursor'.
Ctrl+Shift+C not working
Ctrl+Shift+Up/Down Arrow not working.
I uninstalled Delphi, uninstalled English language, removed keymappings to change keyboard layout (Ctrl+Shift).
Then I installed Delphi again, custom location, execute the installer as administator -> no issues.
I installed the third party components -> no issues
To install the update pack, this time, I opened the exe with winrar, decompressed the file, changed the files 'setup.exe', '_ISDel.exe' and '_BDEL.EXE' to execute always as administrator for all users. Run 'setup.exe' as administrator.
I don't know exactly which step did the trick but now I have no Issues.
I just tried with Delphi 6 on Win64, and have all the windows. And all expected menu items. Sometimes, there is some problems of refresh, but when I restart the IDE, everything is back there.
But I've installed:
Delphi 6 Suite Entreprise;
Update pack 2;
DDevExtension;
Delphi SpeedUp;
CnPack.
All is installed not in C:\Program Files but in a custom C:\Progs directory, which has all security rights set for all authenticated users. You should not install Delphi 6 under C:\Program Files, in all cases.
Works like a charm. Perhaps one of the add-ons fixed the issue.
I have a Delphi .CPL currently written with Delphi 7 which needs to update settings in HKLM (to be used by a service application) and which must support Vista, Win7 and Server 2008. Currently this can be done by adding a RUNASADMIN value to AppCompatFlags/Layers, using the CPL file as the value name. This causes Windows to ask for elevation for a 'legacy control panel applet'.
I need to find a way to build the CPL in Delphi 2010 without it appearing to be 'legacy' and, if possible, not to require the registry setting or elevation. Adding the usual manifest resource to the DLL/CPL referencing Common-Controls v6 and "requireAdministrator" does not fix the problem: no elevation is requested and HKLM access fails. Both the original and the Delphi 2010 .CPL can be made to run correctly (after elevation) by navigating to the file in SYSWOW64, right-clicking, and running 'as Administrator'.
Later: I have found a succint explanation of why you cannot elevate a DLL in this way in a forum posting here.
I believe you need to use COM elevation. There was a wonderful blog posting on this which appears to have been taken down, but the source code behind the posting is still available on the VCL components website (way back machine link).
Some additional information can be found in the question/answers for: Delphi: Prompt for UAC elevation when needed
I think I have found a better answer to my question. There is such an animal as a 'non-legacy' control panel applet, which is described in MSDN here. "Now, in Windows Vista, you can add your own applet to Control Panel by creating an executable for your applet and registering it, instead of going through the trouble of creating a .cpl file."