I store the icons for my applications inside several image lists.
Have one to:
X16
X24
X48
X32
Both TActions and direct access to place ICOs in a TButton, or TImage came from this several Image Lists.
My problem is that when I need to remove one its nightmare
I thought of setting a CONST value to everyone, but as some are used in TActions it’s not a complete solution.
How are you guys doing this and what solutions do you have to solve or at least improve this?
I use DELPHI 2007.
What I do is add all the icons at runtime by loading from then from resources. When I add them I save the index of the added icon to a global variable. I also assign the ImageIndex property of each action at runtime by referring to these global variables.
This allows flexibility to add and remove icons to the project without having numbering problems. The approach caters for runtime icon size decisions based on font scaling. The drawback is that you don't get to see the images at design time which is a drawback. If you want to have all the flexibility outlined above I don't see a better solution. In an ideal world the images would be identified by a name or an ID rather than a contiguous index into an array. But to achieve that you would need to implement a lot of code on top of the VCL.
There are several solutions to this problem.
If you want to use constants, but you don´t want to change them all each time you remove an image. You can do the following:
const
idImgA = 0;
idImgB = idImgA + 1;
idImgC = idImgB + 1;
idImgD = idImgC + 1;
idImgE = idImgD + 1;
idImgF = idImgE + 1;
idImgG = idImgF + 1;
When you want to remove image D, you only need to change two lines:
const
idImgA = 0;
idImgB = idImgA + 1;
idImgC = idImgB + 1;
idImgE = idImgC + 1;
idImgF = idImgE + 1;
idImgG = idImgF + 1;
Another way is to work with enum types:
type
TImgEnum = (imgA, imgB, imgC, imgD, imgE, imgG);
You can use the Ord operator to get the image index:
index := Ord(Enum);
Related
I'm developing a library for reading CD-ROMs and the ISO9660 file system.
Long story short, pretty much everything is working except for one thing I'm having a hard time figuring out how it's done:
Where does XA standard defines differentiation among Mode 2 Form 1 from Mode 2 Form 2?
Currently, I am using the following pseudo-code to differentiate between both forms; albeit it's a naive heuristic, it does work but well, it's far from ideal:
var buffer = ... // this is a raw sector of 2352 bytes
var m2F1 = ISector.Cast<SectorMode2Form1>(buffer);
var edc1 = EdcHelper.ComputeBlock(0, buffer, 16, 2056);
var edc2 = BitConverter.ToUInt32(m2F1.Edc, 0);
var isM2F1 = edc1 == edc2;
if (isM2F1) return CdRomSectorMode.Mode2Form1;
// NOTE we cannot reliably check EDC of M2F2 since it's optional
var isForm2 =
m2F1.SubHeaderCopy1.SubMode.HasFlag(SectorMode2Form1SubHeaderSubMode.Form2) &&
m2F1.SubHeaderCopy2.SubMode.HasFlag(SectorMode2Form1SubHeaderSubMode.Form2);
if (isForm2) return CdRomSectorMode.Mode2Form2;
return CdRomSectorMode.Mode2Formless;
If you look at some software like IsoBuster, it appears to be a track-level property, however, I'm failing to understand where the value would be read from within the track.
I'm actually doing something similar in typescript for my ps1 mod tools. It seems like you actually probably have it correct here, since I'm going to assume your HasFlag check is checking position bit position 6 of the subheader. If that flag is set, you are in form 2.
So what you probably want something like:
const sectorBytes = new Uint8Arrray(buffer);
if (sectorBytes[0x012] & 0x20) === 0x20) {
return CdRomSectorMode.Mode2Form2;
} else {
return CdRomSectorMode.Mode2Form1;
}
You could of course use the flag code you already have, but that would require you to use one of the types first to get that. This just keeps it generic bytes and checks the flag, then returns the relevant mode.
I want to merge two sets of fluorescence microscope images into a green & blue image, but I'm having trouble with the macro (haven't used ImageJ before). I have a folder of FITC-images to be coloured green and a folder of DAPI-images to be coloured blue. I have been using this modified version of a macro I found online:
macro "batch_merge_channel"{
count = 1;
setBatchMode(true);
file1= getDirectory("Choose a Directory");
list1= getFileList(file1);
n1=lengthOf(list1);
file2= getDirectory("Choose a Directory");
list2= getFileList(file2);
n2=lengthOf(list2);
open(file1+list1[1]);
open(file2+list2[1]);
small = n1;
if(small<n2)
small = n2;
for(i=0;i<small;i++)
{
run("Merge Channels...", "c2="+list1[1]+ " c3="+list2[1]+ " keep");
name = substring(list1, 0, 13)+")_merge";
saveAs("tiff", "C:\\Merge\\"+name);
first += 2;
close();
setBatchMode(false);
}
This, however returns an error
x.tif is not a valid choice for "C2 (green):"
with x being the name of the first file in the first folder.
If I merge the images manually, two by two, there is no error. So I'm presuming the problem is in the macro code.
I found several cases of this error online, but none of the solutions that seemed to work for those people work for me.
Any help would be appreciated!
In case you didn't solve this already, a great place to get help on ImageJ questions is the forum.
I can suggest a couple of ideas:
Is your image successfully opened by the macro? You could set the batch mode to false to check this.
It looks to me like the for loop does not employ the variable i. It works on the first pair of
images (list1[1], list2[1]), then closes the merged image, but then
tries to process image 1 again. To actually loop through all the
images in the folder, you have to put inside the loop something
like this (you don't need 'keep' -- better to leave it out so the source images will automatically be closed)
open(file1+list1[i]);
open(file2+list2[i]);
run("Merge Channels...", "c2="+list1[i]+ " c3="+list2[i]);
-- Turning off batch mode should be done after the loop, not within the loop.
Here's a version that works for me.
// #File(label = "Green images", style = "directory") file1
// #File(label = "Blue images", style = "directory") file2
// #File(label = "Output directory", style = "directory") output
// Do not delete or move the top 3 lines! They contain essential parameters
setBatchMode(true);
list1= getFileList(file1);
n1=lengthOf(list1);
print("n1 = ",n1);
list2= getFileList(file2);
n2=lengthOf(list2);
small = n1;
if(small<n2)
small = n2;
for(i=0;i<small;i++)
{
image1=list1[i];
image2=list2[i];
open(file1+File.separator+list1[i]);
open(file2+File.separator+list2[i]);
print("processing image",i);
run("Merge Channels...", "c2=&image1 c3=&image2");
name = substring(image1, 0, 13)+"_merge";
saveAs("tiff", output+File.separator+name);
close();
}
setBatchMode(false);
Hope this helps.
I am welcoming Embarcaderos efforts to make TListView more dynamically, and was exited to see Sarina Duponts post here where you could just link the imageindex to the TListView properties in LiveBindings Designer, and even the image property to a datafield (integer) when using DynamicAppearance and TImageObjectAppearance.
But... I tried, and did almost succeed.
In my challenge I have an application where I use TFDMemTable with TREST* function to populate the TFDMemTable. All works well if I don't use the DynamicAppearance and use i.e. ImageListItem and links the datafield I want to use to the imageindex property in TListView using LiveBindings Designer.
With DynamicApperance though, there are no imageindex property to link to, but Sarina Dupont says in here post that you could link the integer field directly to the image property (and IDE/compiler will figure it out).
Well... I figured following out: My data fields (semicreated from TREST* and TFDMemTable) are not neccesserely what they seems to be. Since I am using REST/JSON, the fieldtypes are "anonymized" to WideString, actually the FieldDefs->'dataitem'->DataType is set to "ftWideString". I tried to change this value to ftInteger in hope that this would help, but I did just get this errormessage: "FDMemtTable1: Type mismatch in field for 'datafield', exepecting: WideString actual: Integer".
So... I was nearly there, and I really want to use DynamicAppearance and view several images and textfields for each TListViewItem...
...or is it easier to make a ListViewItem 'Template' dynamically and populate it with data instead, and what is the best way to do that ?
I usually try to avoid LiveBindings. The fastest, most stable and easiest way is to add items using code.
ListView1->BeginUpdate();
try {
for (int i = 0; i < arrayOfThings->item.Length; i++) {
TListViewItem* item = ListView1->Items->Add();
item->Text = arrayOfThings->item[i]->item_name;
item->Data["itemName"] = TValue::From<UnicodeString>( arrayOfThings->item[i]->item_name);
item->Data["itemId"] = TValue::From<UnicodeString>( IntToStr( arrayOfThings->item[i]->id ));
item->Data["itemDate"] = TValue::From<UnicodeString>(arrayOfThings->item[i]->item_date);
// adding the image - imgClock is name of the image field [TImageObjectAppearance ] added to items in ItemAppearance in the TListView object that uses DynamicAppereance
const UnicodeString imgClock = L"imgClock";
dynamic_cast<TListItemImage*>(item->Objects->FindDrawable(imgClock))->Bitmap = //bitmap source;
}
} catch (...) {
}
ListView1->EndUpdate();
i choose to ask a question here well aware that i can infringe some rules of StackExchange maybe becouse this isn't the right place to ask that, but i saw a lot of question related to CERN ROOT. I know that here people that answer the questions prefer to show the way instead to give a cooked solution, but i need some help and i have no time to learn from the answers, i only want a solution for my problem. I apologize in advance!
Here is my problem: i have two .root files:
one of a spectrum ("sezione_misura_90.root"),
one from background ("sezione_fondo_90.root").
I have to subtract the second from the first and get a final histogram. Usually i open the file with the TBroswer and i have no idea how to implement a macro of a script to open a .root file or doing everything else, first of all becouse i hate ROOT and all programming related, and i have only a course where i am supposed to use that, without someone tell me how!!! Even the prof. don't know how to use...
If some one that read have a macro or a script ready to use, I will be forever indebted to him for sharing that with me. Thanks in advance!
EDIT
I write down a file named run.cxx with the following lines
int run()
{
// Open both files side-by-side
TFile* sezione_misura_90 = new TFile("sezione_misura_90.root");
TFile* sezione_fondo_90 = new TFile("sezione_fondo_90.root");
// Get the histograms from the file
// Since you didn't say from your post, I'm going to assume that
// the histograms are called "hist" and that they hold floating
// point values (meaning, they're TH1F histograms. The "F" means float)
TH1F* h_misura = (TH1F*) sezione_misura_90->Get("hist");
TH1F* h_fondo = (TH1F*) sezione_fondo_90->Get("hist");
// Now we add them together
TH1F* h_sum = h_misura->Add(*h_fondo, -1);
}
There was some typos like ( and ;, i correct them but i get back the following.
Error: illegal pointer to class object h_misura 0x0 139 run.cxx:21:
** Interpreter error recovered **
A simple way to accomplish this is to write a script that opens the two files, reads the histograms from the files, and subtracts them (which is the same as adding them using a factor of -1). This can be done using a block of code similar to the following:
{
// Open both files side-by-side
TFile* sezione_misura_90 = new TFile("sezione_misura_90.root");
TFile* sezione_fondo_90 = new TFile(("sezione_fondo_90.root");
// Get the histograms from the file
// Since you didn't say from your post, I'm going to assume that
// the histograms are called "hist" and that they hold floating
// point values (meaning, they're TH1F histograms. The "F" means float)
TH1F* h_misura = (TH1F*) sezione_misura_90->Get("hist");
TH1F* h_fondo = (TH1F*) sezione_fondo_90->Get("hist");
// Now we add them together
TH1F* h_sum = h_misura->Add(*h_fondo, -1);
}
At this point, h_sum should be the histogram you want. You can save it to a file for later reading, or you can draw it to the screen if you're running an interactive root session.
The above code can be run by doing one of the following:
An interactive root session just by typing root and then typing the above lines)
As a root script (by pasting them into a file which, for example, could be named "file.C" and typing "root file.C")
A larger program (by putting the above lines in a function and calling that function)
You can read more about the methods available for a Histogram in ROOT's documentation:
http://root.cern.ch/root/html/TH1.html#TH1:Add#1
Hope that helps.
I see at least two problems. One problem has to do with the way ROOT manages memory, more specifically ROOT objects in memory:
// Each ROOT object derives from a TNamed class,
// hence has a <name>, which ROOT uses internally
// to keep track of the objects
TH1F* h_misura = (TH1F*) sezione_misura_90->Get("hist");
// now you have a histogram named "hist" in memory;
//btw, better to name it something more unique, e.g. hist1, at least
TH1F* h_fondo = (TH1F*) sezione_fondo_90->Get("hist");
// And now, you are trying to get another histogram named "hist",
// which creates a problem: Two different histograms with the same
// name - you can't do that.
// At the very least ROOT is going to overwrite the first hist
// and replace it with the second, or bug out
Solution to problem one:
// Rename the "hist"s to something like "hist1" and "hist2"
TH1F* h_misura = (TH1F*) sezione_misura_90->Get("hist");
h_misura->SetName("hist1");
TH1F* h_fondo = (TH1F*) sezione_fondo_90->Get("hist");
h_fondo->SetName("hist2");
// now, you have to histograms in memory with unique names
Problem two: when you open a TFile with
// TFile * f = new TFile("file.root");
it opens it in a read-only mode, therefore you can't write to them if you want to save your sum of histograms. Instead do this:
TFile * f = TFile::Open("file.root", "write");
// and do a null pointer check
if (!f) { std::cout << "file not found" << std::endl; exit(1); }
// if you want to save the results to file f
// ...
f->cd();
hist->Write();
f->Close();
I've been having difficulty identifying the correct parameters for the PresentParameters and DirectX device, so that there can be both vertex-level gouraud shading and the use of a z buffer. Some triangle meshes work fine, others have background triangles appearing in front of triangles which are closer-to-camera.
An example of this is found here: http://gallery.me.com/robert.perkins/100045/zBufferGone. The input data is a simple list of vertices in facets. The winding order of the vertices in each facet is nondeterministic (comes from various CAD software export functions) and there is no normals data.
The PresentParameters are being set up right now as follows. I realize this is C# instead of C++ but I think it's descriptive enough, and the parameters pass through to C++ code. This produces the image in the picture; the behavior is the same on the Reference device:
pParams = new PresentParameters()
{
BackBufferWidth = this.ClientSize.Width,
BackBufferHeight = this.ClientSize.Height,
AutoDepthStencilFormat = Format.D16,
EnableAutoDepthStencil = true,
SwapEffect = SwapEffect.Discard,
Windowed = true
};
_engineDX9 = new EngineDX9(this, SlimDX.Direct3D9.DeviceType.Hardware, SlimDX.Direct3D9.CreateFlags.SoftwareVertexProcessing, pParams);
_engineDX9.DefaultCamera.NearPlane = 0;
_engineDX9.DefaultCamera.FarPlane = 10;
_engineDX9.D3DDevice.SetRenderState(RenderState.Ambient, false);
_engineDX9.D3DDevice.SetRenderState(RenderState.ZEnable, ZBufferType.UseZBuffer);
_engineDX9.D3DDevice.SetRenderState(RenderState.ZWriteEnable, true);
_engineDX9.D3DDevice.SetRenderState(RenderState.ZFunc, Compare.Always);
_engineDX9.BackColor = Color.White;
_engineDX9.FillMode = FillMode.Solid;
_engineDX9.CullMode = Cull.None;
_engineDX9.DefaultCamera.AspectRatio = (float)this.Width / this.Height;
All of my other setup attempts, even on the reference device, return a COM error code ({"D3DERR_INVALIDCALL: Invalid call (-2005530516)"}). What are the correct setup parameters?
EDIT: The C++ class which interfaces with DirectX9 sets defaults like this:
PresentParameters::PresentParameters()
{
BackBufferWidth = 640;
BackBufferHeight = 480;
BackBufferFormat = Format::X8R8G8B8;
BackBufferCount = 1;
Multisample = MultisampleType::None;
MultisampleQuality = 0;
SwapEffect = SlimDX::Direct3D9::SwapEffect::Discard;
DeviceWindowHandle = IntPtr::Zero;
Windowed = true;
EnableAutoDepthStencil = true;
AutoDepthStencilFormat = Format::D24X8;
PresentFlags = SlimDX::Direct3D9::PresentFlags::None;
FullScreenRefreshRateInHertz = 0;
PresentationInterval = PresentInterval::Immediate;
}
Where does it return an invalid call?
Edit: I'm assuming in the new EngineDX9 call? Have you tried setting a device window handle in the present parameters?
Edit 2: Have you turned on the debug spew in the DirectX control panel to see whether it tells you what the error is?
Edit3: You have tried setting backbufferWidth and Height to 0? What is backbuffercount set to? Might also be worth trying "Format.D24S8" on the backbuffer? Its "possible" your graphics card doesn't support 16-bit (unlikely though). Have you checked in the caps that the mode you are trying to create is valid? I asssume, btw, that the CLR language you are using automagically sets the parameters you don't set to 0? I,personally, always prefer to be explicit in such cases ....
PS I'm guessing here because im a native C++ DX9 coder not a CLR SlimDX coder ...
Edit4: I'm sure its the lack of window handle ... I'm probably wrong but thats the only thing i can see REALLY wrong with your setup. A windowed DX9 device requires a window. Btw set width and height to 0 to just use the window you are setting the device too's size ...
Edit 5: I've really been heading down the wrong route here. There is nothing wrong with the creation of the device that produced your "incorrect" device. Do not mess with the present parameters they are fine. The main reason you'll have problems with your Z-Buffering is that you set the compare function to always. This means that, regardless of what the z-buffer contains, pas the pixel and write its z into the z-buffer overwriting whatever is there already. I'd wager therein lies your Z-buffering problem.