Does anybody know if it is possible to visually see and edit components at developing time? i would like to create a component based on TPanel, but i dont have any design window (or dfm) where i can visually add components on it, i found related threads in which some programmers claim its not possible.
Any ideas if its possible and how?
thnx
Nope. Using frames is the best you can do to develop compound components with the aid of the visual designers.
See this article http://etutorials.org/Programming/mastering+delphi+7/Part+II+Delphi+Object-Oriented+Architectures/Chapter+9+Writing+Delphi+Components/Creating+Compound+Components/
And specifically the section "Building Compound Components with Frames".
Make a project group.
Add a package to that project group.
Add/install a component in that package.
Add a VCL forms application to the project group.
Right click on a project group and choose build all.
This way you will be able to 'visually' track the progress of your component during the development.
An alternative to compound components is to use component templates.
They're not proper components, rather they're just a shortcut to you copying and pasting the components and their event handlers from one form to another. You can manipulate them using the designer though so they may be suitable for your purposes.
what you are asking is, I believe, is how to create components and interact with them at design time no ?(by example the behavior of datasets, properties of a form,etc).
here you have an example
http://www.podgoretsky.com/ftp/docs/Delphi/D5/dg/register.html
best regards,
Radu
I take this question to mean that you wish to develop a custom component and to do so visually rather than in code. If that is your question then I'm afraid that you can't do it.
Related
I want to create a project in the JIRA.
The project should be able to select the type of work and choose another project.
I wish user can create selected another project because there are many large numbers of projects.
and type of work can choose two or three depth.
First.
type of work use customfield.
choose another project use component.
-Team member should be an administrator permission in project.
Second
type of work use customfield.
choose another project use label.
Is there a better plan?
Last I want to know difference between label and component and version.
I think user can create label and project admin can create label, component, and version. The label applies entirely. But component and version applies project.
It sounds like you may be trying to do something which I don't think is possible: an issue is in exactly one project at a time.
Components are a lot like labels, but are selectable from a set defined for a project. It can sometimes be useful to define components which align across multiple projects. You're correct that creating components requires admin privileges, while anyone can create labels; this can make for an excess of different labels if they aren't used with some care and discipline, but the components list will stay as clean as the admins keep it. An issue can relate to multiple components and have multiple labels. Sharing labels or components across projects may achieve what you're after.
Because components are a "privileged" class of labels, it's often wise to spend a bit of time considering a sensible scheme for them based on the anticipated breakdown of issues; changing them in bulk midway through a project can be tedious.
I'm less familar with versions; I'm not sure whether an issue can be linked to multiple versions. They are usually used to group issues for release planning, but that isn't imposed by the tool, they could be used for something else; it might be confusing for users making assumptions about what "Version" means, though.
It's difficult to answer your question, as there are some grey areas, but will try to briefly explain the difference between labels, components and version.
Project and components
First of all, a project is (a project) a collection of issues (stories, tasks, bugs, etc.), so components are just sub-sections of a project. They could be either defined based on the architecture of your product. Also, a component can be assigned by default to a particular user or group. An example of components could be database, UI, notifications.
Labels
Labels help you categorise and search for an issue and have the advantage of allowing multiple labels to an issue.
Versions
A version is a set of stories and bug-fixes and helps you plan the release of those stories and fixes to the customer.
The main way to categorise the type of work within a project is to add different types of issues and for each one define custom fields, screens, and workflows.
Hope that helps you address the problem!
How to use checkboxes inside a standard TDBGrid to select multiple records? Or perhaps, do you have any recommendation for a free/open source sister of DBGrid that allows anyone to do that easily?
Thank you.
Nevermind, I found Mike Shkolnik's SMDBGrid from a thread about Delphi free & open source components. This is exactly what I'm looking for.
You can check this product, although this is not open-source or free, but is a great look and feel for the UI.
http://www.devexpress.com/Products/VCL/ExQuantumGrid/
I'm new to delphi and I'm looking up on ways to learn more about delphi underlying technology plus make something useful here in my job in the process, also if anyone has any tip or see anyway i can improve my idea please fell free to speak your mind...
i want to do make some kind of Scaffolding for dfms, the ideia is the following: i want to generate based on a firebird database table - with well defined domains - the bulk of the Form .
I think the idea is too simple or i'm not seeing the big picture that makes it difficult, i'm trying not to reinvent the well, i've looked up on google but without good results, so if anyone could giveme a direction here i would be most grateful.
UPDATE:
#Larry Lustig thanks, i didn't think about delphi frameworks - i'm going to look them up.
i know something about form objects/handling and database metadata, but i'm unfamiliar with serilizing delphi objects to the HD. Any tips on Serialization and delphi frameworks (opensource so i could take a look :) ) would be welcome!
Sounds like an interesting idea.
Instead of writing a DFM form manually on disk I would use the following approach:
Get the structure of your table by examining the meta data.
Create a TForm and add a control to it for each column you want to represent.
Use Delphi's built in serialization to save the form to disk.
I haven't done this myself, but there are a number of run-time design frameworks that work using this idea.
This would only make sense if you need to build a lot of forms at design time. You can't use the DFM's in your executable's. If you want to build the forms runtime, I suggest you go with Larry Lustig's answer.
We have taken this one step further... we don't build forms. We only write the classes, add some attributes and create the forms at runtime. Users can change this preset form layout during runtime and save their own layout. Data binding between the controls and the database is done with the excellent tiOPF framework. Maybe something you can consider to use as well.
Is "Replacing non-visual components with code" a proven optimization technique in Delphi 7. Mainly with respect to Database Access.
The Web site you cite talks about replacing a dialog-box component with code that would display the dialog box without the use of any component. The alternative is to write a couple of lines of code to set up and display a dialog box whenever you need one, and to skip the component altogether. It's not really an optimization in speed or size, though. It's not a speed optimization since your code would do exactly what a component would have done anyway, and it's not a size optimization because the space any one component occupies in a program is negligible.
Database components aren't so easily replaceable as dialog-box components. Nearly everything in Delphi is designed to use descendants of the standard database components. If you don't use the components, then you won't be using any of Delphi's database capabilities at all. You can use the database libraries' native APIs if you wish, but I think that would be foolish if your goal is really optimization and you haven't identified the components as the source of your program's non-optimal behavior. Consider how much time and effort it would take you to rewrite your program without the database components.
I don't see how a form-based dataset/query/table/etc., would be faster or slower than one created in code. However, I like to put them in code as it's easier to maintain. I've seen screens with SQL embedded in a component, and then it's overridden in the code. Then I have to stop and investigate to determine which SQL is actually in effect. Sometimes the SQL in the form is good, sometimes it's used for a while and then trumped by the code, sometimes it's never active and the SQL is trumped in the formcreate. So I have to determine whether this is by design, or just sloppy leftovers. Also, it's easy to miss SQL changes in code reviews if they're in the .DFM and not the .PAS. i.e. I don't always look at the .DFM because I'm not interested in whether a label caption changed or a button moved.
So while it's nice for prototyping, when it comes to production code, you're better off having all of your database logic (SQL, table and field definitions) in the .pas file.
Update: I have finally given CnPack a try. Among the dozens of goodies, is a brilliant tool called "convert selected components to code". Form Design Wizard | More... | Convert Selected Components To Code. It does it all for you.
This is not a matter of being a component or not a component. If it comes to database access then BDE is extremely slow so changing it for sth else is a good move.
By the way - optimization is not about 'proven techniques' - it's about identifying a problem and solving it. If the problem happens to be slow db access then this is what you have to change.
Generally no. There is no additional overhead in using a non-visual component. It is created very quickly and works at runtime exactly at the same speed as one "created in code".
I'd like to create a custom "datamodule" in Delphi, a TDataModule like (maybe inherited) class which would have a custom grid based design interface (one component per line, some properties as columns). Is this possible? Where should I start?
I'm currently using Delphi 2007.
Maybe it is possible. An example of a XML Frame Designer can be found on the page New IDE Building Blocks. Well this example is for Delphi 5, but it might be a good starting point.
As Nick Hodges pointer out here:
Drawing on a DataModule in Delphi
it would be difficult to paint on the TDataModule descendant. Not impossible probably, but not worth the trouble for sure.
I would consider designing a completely new TDataModule from scratch, so you would have complete control over it. Sure a lot of work probably, but in the end it would pay off.
You can find TDataModule class in the Classes.pas unit. But this is just the runtime part of the code. Other parts are IDE related. You can find units related to ToolsAPI in "c:\Program Files\Borland\BDS\4.0\source\ToolsAPI\" for BDS 2006 for instance. You can also derive you own data module from TDataModule and register it with RegisterCustomModule (DesignIntf.pas). I don't know much more on this subject, maybe others do. As I said it would not be easy to do something like that. But maybe with this initial information you can find what you want.
It's not possible exactly as you describe it. You can't place visual components like a grid on a data module. You need a form or frame for that.
If I were to do try to something like you're describing, I'd use a list box to hold a list of individual components, a couple buttons and a selection dialog box for adding and deleting components from the list, and the TJvInspector component from the JVCL for modifying properties. That would be a lot easier than trying to make a one-size-fits-all grid to handle the situation.